Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve efficiency of muted TCPConnection on non Windows platforms #1477

Merged
merged 1 commit into from
Dec 19, 2016

Conversation

SeanTAllen
Copy link
Member

Prior to this commit, if we were in TCPConnection's _pending_reads
and encountered discovered that the connection was muted, we would
call read_again to requeue another read and would then return.

This results in a lot of extra, unneeded work. Until the connection
is unmuted, there's no point to calling read_again, we'll just keep
repeating the same cycle over and over again; pointlessly putting
messages on the TCPConnection's queue.

With the commit, we now return from _pending_reads when discovering
that the connection is muted without calling read_again. Instead,
when we unmute the connection, we will then immediately call
_pending_reads to start processing any unhandled data.

There is probably a similar improvement that can be made on Windows,
however, I'm not a Windows programmer, barely know IOCP at all and
am more likely to break the Windows TCP implementation than I am
improve it therefore, this commit only applies to non Windows platforms.

Prior to this commit, if we were in TCPConnection's _pending_reads
and encountered discovered that the connection was muted, we would
call read_again to requeue another read and would then return.

This results in a lot of extra, unneeded work. Until the connection
is unmuted, there's no point to calling read_again, we'll just keep
repeating the same cycle over and over again; pointlessly putting
messages on the TCPConnection's queue.

With the commit, we now return from _pending_reads when discovering
that the connection is muted without calling read_again. Instead,
when we unmute the connection, we will then immediately call
_pending_reads to start processing any unhandled data.

There is probably a similar improvement that can be made on Windows,
however, I'm not a Windows programmer, barely know IOCP at all and
am more likely to break the Windows TCP implementation than I am
improve it therefore, this commit only applies to non Windows platforms.
@SeanTAllen SeanTAllen added the changelog - fixed Automatically add "Fixed" CHANGELOG entry on merge label Dec 18, 2016
@jemc jemc merged commit 53bf771 into master Dec 19, 2016
@jemc jemc deleted the more-efficient-mute branch December 19, 2016 16:50
ponylang-main added a commit that referenced this pull request Dec 19, 2016
SeanTAllen added a commit that referenced this pull request Dec 23, 2016
…1477)

Prior to this commit, if we were in TCPConnection's _pending_reads
and encountered discovered that the connection was muted, we would
call read_again to requeue another read and would then return.

This results in a lot of extra, unneeded work. Until the connection
is unmuted, there's no point to calling read_again, we'll just keep
repeating the same cycle over and over again; pointlessly putting
messages on the TCPConnection's queue.

With the commit, we now return from _pending_reads when discovering
that the connection is muted without calling read_again. Instead,
when we unmute the connection, we will then immediately call
_pending_reads to start processing any unhandled data.

There is probably a similar improvement that can be made on Windows,
however, I'm not a Windows programmer, barely know IOCP at all and
am more likely to break the Windows TCP implementation than I am
improve it therefore, this commit only applies to non Windows platforms.
SeanTAllen pushed a commit that referenced this pull request Dec 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog - fixed Automatically add "Fixed" CHANGELOG entry on merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants