Improve Unix synchronous socket perf#5472
Conversation
|
Thanks for doing this, @ericeil. Before I review, just so I understand, we still follow the existing sync-over-async code paths and have extra expenses like the allocation of the MRES here ( ), but the operation will actually always complete synchronously and thus we always take the fast path out, right? Or have I misunderstood? |
|
@stephentoub, that's right. |
|
Looks like there's a test hanging. I'll look at it. |
There was a problem hiding this comment.
I wonder if we should either change the native signature to not even allow setting back to blocking, or potentially just add an assert to the native function that verifies we're only ever setting it to non-blocking and not to blocking.
|
LGTM, other than the test failure. |
|
Did you figure out the cause of the hang? |
|
I think I just figured out the hang. It looks like we expect |
… begin an async operation. For blocking sockets that never start an async operation, this avoids the overhead of emulating blocking semantics on top of a non-blocking socket.
Dispose does not cancel Accept.
…pose does not cancel Accept." It looks like this trick does not work on Windows or OSX, both of which return errors if Shutdown is called on an unconnected socket. This reverts commit bc8b171.
|
@dotnet-bot test Innerloop CentOS7.1 Debug Build and Test |
|
@dotnet-bot test Innerloop CentOS7.1 Release Build and Test |
Improve Unix synchronous socket perf
Improve Unix synchronous socket perf Commit migrated from dotnet/corefx@14d29e7
6 participants
Synchronous operations on sockets are currently always emulated in terms of async/non-blocking operations. This has quite a lot of run-time overhead, due to extra system calls, context switches, etc.
With this change we keep the socket in "blocking" mode until the user requests non-blocking mode or initiates an asynchronous operation. The result is that a socket that only ever experiences synchronous operations will not have the overhead of emulating sync over async.