Handle EAGAIN in Console.Write on Unix #23539
Conversation
If stdout/stderr is configured as a non-blocking file descriptor, Console.Write{Line} may fail if the descriptor is full and would block. With this commit, we instead poll in that case waiting for the ability to write and then retry.
stephentoub
changed the title
|
It looks good to me @stephentoub . Out of curiosity: what would be behavior of the new test if you comment out your fix. |
Thanks
There's a race condition involved, so it won't fail 100% of the time, but in most executions it'll fail with an exception that stems from this line translating the received EAGAIN/EWOULDBLOCK into an exception: |
|
I think that is good enough. I was wondering is stdout is hijacked by xunits in this case. |
No, the test is using our RemoteInvoke helper to run the relevant code in a separate process: |
|
great. thanks for clarification @stephentoub That is good trick to know. |
If stdout/stderr is configured as a non-blocking file descriptor, Console.Write{Line} may fail if the descriptor is full and would block. With this commit, we instead poll in that case waiting for the ability to write and then retry.
release/2.0: Handle EAGAIN in Console.Write (#23539)
If stdout/stderr is configured as a non-blocking file descriptor, Console.Write{Line} may fail if the descriptor is full and would block. With this commit, we instead poll in that case waiting for the ability to write and then retry.
Commit migrated from dotnet/corefx@e84604e
If stdout/stderr is configured as a non-blocking file descriptor, Console.Write{Line} may fail if the descriptor is full and would block. With this commit, we instead poll in that case waiting for the ability to write and then retry.
(This should workaround the issue seen in dotnet/msbuild#2153, though it'd be good to understand why stdout is being set as O_NONBLOCK in that scenario, who's doing it, etc.)
cc: @joperezr, @wfurt, @CESARDELATORRE