event: support pipe sources on Windows #501
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ktopley-apple
suggested changes
Jun 24, 2019
ktopley-apple
approved these changes
Jun 26, 2019
|
@swift-ci please test |
This implements full support for using pipe sources on Windows to trigger an event when a pipe becomes readable or writable. Due to differences between the Windows asynchronous I/O model and the Unix model, this is rather complex. On Windows, the standard mechanism to achieve asynchronous pipe I/O is to just read or write from the pipe and then get notified once the operation completes. Unlike the Unix `select()`/`poll()` model, there is no way to simply know when a pipe becomes readable or writable without actually running an operation. So we need to resort to several tricks in order to achieve the semantics that Dispatch wants here. To monitor a pipe for readability, we take advantage of the fact that a zero-byte `ReadFile()` on a pipe will block until data becomes available in the pipe. A muxnote which monitors a pipe for reading will spin up a lightweight thread which repeatedly calls `ReadFile()` (blocking) on the pipe and posts back to the I/O completion queue when it returns. To monitor pipes for writability, we use the `NtQueryInformationFile()` kernel API to get the amount of available space in the pipe's write buffer. There is no way to block here, so we have no choice but to continually disarm and rearm unotes until space becomes available. This is inefficient, but it generally seems to work OK. In order to test this, I implemented a new dispatch_io_pipe test which performs various read and write operations on pipes. On Windows, this will run the tests on most of the different pipe kinds (anonymous, named, inbound, outbound, overlapped). This caught a lot of issues in the Windows `_dispatch_operation_perform()` which I fixed along the way. The dispatch_io and dispatch_io_pipe_close tests pass as well with my other pull request applied.
|
Fixed the build failure in Release mode and a merge conflict that arose. cc @ktopley-apple |
|
@swift-ci please test |
1 similar comment
|
@swift-ci please test |
compnerd
reviewed
Jun 27, 2019
| @@ -103,17 +136,28 @@ _dispatch_muxnote_create(dispatch_unote_t du) | |||
| // The specified file is a character file, typically a | |||
| // LPT device or a console. | |||
| WIN_PORT_ERROR(); | |||
| free(dmn); | |||
| return NULL; | |||
| // We'll get ERROR_ACCESS_DENIED for outbound pipes. | ||
| if (GetLastError() != ERROR_ACCESS_DENIED) { | ||
| // The file is probably a socket. | ||
| WIN_PORT_ERROR(); |
There was a problem hiding this comment.
hopefully SOCKETs end up being easier than pipes.
rokhinip
pushed a commit
that referenced
this pull request
Nov 5, 2021
event: support pipe sources on Windows Signed-off-by: Kim Topley <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This implements full support for using pipe sources on Windows to
trigger an event when a pipe becomes readable or writable.
Due to differences between the Windows asynchronous I/O model and the
Unix model, this is rather complex. On Windows, the standard mechanism
to achieve asynchronous pipe I/O is to just read or write from the pipe
and then get notified once the operation completes. Unlike the Unix
select()/poll()model, there is no way to simply know when a pipebecomes readable or writable without actually running an operation. So
we need to resort to several tricks in order to achieve the semantics
that Dispatch wants here.
To monitor a pipe for readability, we take advantage of the fact that a
zero-byte
ReadFile()on a pipe will block until data becomes availablein the pipe. A muxnote which monitors a pipe for reading will spin up a
lightweight thread which repeatedly calls
ReadFile()(blocking) on thepipe and posts back to the I/O completion queue when it returns.
To monitor pipes for writability, we use the
NtQueryInformationFile()kernel API to get the amount of available space in the pipe's write
buffer. There is no way to block here, so we have no choice but to
continually disarm and rearm unotes until space becomes available. This
is inefficient, but it generally seems to work OK.
In order to test this, I implemented a new dispatch_io_pipe test which
performs various read and write operations on pipes. On Windows, this
will run the tests on most of the different pipe kinds (anonymous,
named, inbound, outbound, overlapped). This caught a lot of issues in
the Windows
_dispatch_operation_perform()which I fixed along the way.The dispatch_io and dispatch_io_pipe_close tests pass as well with my
other pull request applied.