Support pipes on windows #320
Labels
windows
Related to the Windows OS.
Comments
|
This is going to require more research into exactly how windows pipes work compared to unix pipes. There are a lot of tricky details, like anonymous pipes on windows can't be used with IOCP, etc... A first pass may be to expose named pipes in a windows specific extension. Either way, I will punt this until after 1.0 |
|
This would be nice, since named pipes work with IOCP. It's worth noting that files work with IOCP too, and with kqueue & epoll. Anonymous pipes and "console handles" will probably require special treatment for windows. |
|
👍 |
|
@Drakulix: Worth following, as it might be better than fakes pipes that we have right now in mioco. |
|
This may fit with #360's unification. |
|
In general, features that are officially supported on windows via IOCP (like files, named pipes, etc...) can be exposed on windows w/o worrying about a cross platform unification. This would allow third party libs to take a stab at a unified API. |
|
@carllerche my impression is that third-party libs (e.g. capnp-rpc-rust, capnp-gj, gj) rely on mio to do their platform unification. This makes sense to me. There's no point using mio to deal with different platforms' differing nonblocking-io APIs if mio doesn't actually do that, and you still have to worry about interplatform differences. |
Update:While reading the Windows Console (i.e. stdin from a cmd prompt) in a non-blocking line-based fashion while echoing input & supporting arrowkeys/backspace is impossible without a second thread, reading from named pipes should work analogous to reading from sockets. |
|
Oh as an update, I've got some WIP support to get named pipes working with mio: It's likely not working currently and currently my goal is to work towards alexcrichton/tokio-process#2 |
alexcrichton
added a commit
to alexcrichton/mio
that referenced
this issue
Dec 13, 2016
This commit intends to extend the functionality of mio on Windows to support
custom handles being registered with the internal IOCP object. This in turn
should unlock the ability to work with named pipes, filesystem changes, or any
other IOCP-enabled object on Windows. Named pipes are in particular quite
important as they're often a foundational IPC mechanism on Windows.
This support is provided by exporting two new types in a `windows` module. A
`Registration` serves as the ability to register with the actual IOCP port in an
`Evented` implementation. Internally the `Registration` keeps track of what it
was last associated with to implement IOCP semantics. This may one day be
possible to make a zero-sized-type.
The second type, `Overlapped`, is exported as a contract that all overlapped I/O
operations must be executed with this particular type. This ensures that after
an event is received from an IOCP object we know what to do with it. Essentially
this is just a `OVERLAPPED` with a function pointer after it.
Along the way this exposes the `miow` crate as a public dependency of `mio`. The
`CompletionStatus` and `Overlapped` types in `miow` are exposed through the
`Overlapped` type that mio itself exports.
I've implemented [bindings to named pipes][bindings] and I've also got a
proof-of-concept [process management library][tokio-process] using these
bindings. So far it seems that this support in mio is sufficient for building up
these applications, and it all appears to be working so far.
I personally see this as a much bigger committment on the mio side of things
than the Unix implementation. The `EventedFd` type on Unix is quite small and
minimal, but the `Overlapped` and `Registration` types on Windows are just
pieces of a larger puzzle when dealing with overlapped operations. Questions
about ownership of I/O objects arise along with the method of handling
completion status notifications. For now this is essentially binding mio to
stick to at least the same strategy for handling IOCP for the 0.6 series. A
major version bump of mio could perhaps change these semantics, but it may be
difficult to do so.
It seems, though, that the Windows semantics are unlikely to change much in the
near future. The overhead seems to have essentially reached its limit ("bolting
readiness on completion") and otherwise the ownership management seems
negligible.
Closes tokio-rs#252
Closes tokio-rs#320
alexcrichton
added a commit
to alexcrichton/mio
that referenced
this issue
Dec 13, 2016
This commit intends to extend the functionality of mio on Windows to support
custom handles being registered with the internal IOCP object. This in turn
should unlock the ability to work with named pipes, filesystem changes, or any
other IOCP-enabled object on Windows. Named pipes are in particular quite
important as they're often a foundational IPC mechanism on Windows.
This support is provided by exporting two new types in a `windows` module. A
`Registration` serves as the ability to register with the actual IOCP port in an
`Evented` implementation. Internally the `Registration` keeps track of what it
was last associated with to implement IOCP semantics. This may one day be
possible to make a zero-sized-type.
The second type, `Overlapped`, is exported as a contract that all overlapped I/O
operations must be executed with this particular type. This ensures that after
an event is received from an IOCP object we know what to do with it. Essentially
this is just a `OVERLAPPED` with a function pointer after it.
Along the way this exposes the `miow` crate as a public dependency of `mio`. The
`CompletionStatus` and `Overlapped` types in `miow` are exposed through the
`Overlapped` type that mio itself exports.
I've implemented [bindings to named pipes][bindings] and I've also got a
proof-of-concept [process management library][tokio-process] using these
bindings. So far it seems that this support in mio is sufficient for building up
these applications, and it all appears to be working so far.
I personally see this as a much bigger committment on the mio side of things
than the Unix implementation. The `EventedFd` type on Unix is quite small and
minimal, but the `Overlapped` and `Registration` types on Windows are just
pieces of a larger puzzle when dealing with overlapped operations. Questions
about ownership of I/O objects arise along with the method of handling
completion status notifications. For now this is essentially binding mio to
stick to at least the same strategy for handling IOCP for the 0.6 series. A
major version bump of mio could perhaps change these semantics, but it may be
difficult to do so.
It seems, though, that the Windows semantics are unlikely to change much in the
near future. The overhead seems to have essentially reached its limit ("bolting
readiness on completion") and otherwise the ownership management seems
negligible.
Closes tokio-rs#252
Closes tokio-rs#320
|
Ok I've posted a PR for custom handle registration and the |
alexcrichton
added a commit
to alexcrichton/mio
that referenced
this issue
Dec 14, 2016
This commit intends to extend the functionality of mio on Windows to support
custom handles being registered with the internal IOCP object. This in turn
should unlock the ability to work with named pipes, filesystem changes, or any
other IOCP-enabled object on Windows. Named pipes are in particular quite
important as they're often a foundational IPC mechanism on Windows.
This support is provided by exporting two new types in a `windows` module. A
`Binding` serves as the ability to register with the actual IOCP port in an
`Evented` implementation. Internally the `Binding` keeps track of what it
was last associated with to implement IOCP semantics. This may one day be
possible to make a zero-sized-type.
The second type, `Overlapped`, is exported as a contract that all overlapped I/O
operations must be executed with this particular type. This ensures that after
an event is received from an IOCP object we know what to do with it. Essentially
this is just a `OVERLAPPED` with a function pointer after it.
Along the way this exposes the `winapi` crate as a public dependency of `mio`.
The `OVERLAPPED_ENTRY` and `OVERLAPPED` types in `winapi` are exposed through
the `Overlapped` type that mio itself exports.
I've implemented [bindings to named pipes][bindings] and I've also got a
proof-of-concept [process management library][tokio-process] using these
bindings. So far it seems that this support in mio is sufficient for building up
these applications, and it all appears to be working so far.
I personally see this as a much bigger committment on the mio side of things
than the Unix implementation. The `EventedFd` type on Unix is quite small and
minimal, but the `Overlapped` and `binding` types on Windows are just
pieces of a larger puzzle when dealing with overlapped operations. Questions
about ownership of I/O objects arise along with the method of handling
completion status notifications. For now this is essentially binding mio to
stick to at least the same strategy for handling IOCP for the 0.6 series. A
major version bump of mio could perhaps change these semantics, but it may be
difficult to do so.
It seems, though, that the Windows semantics are unlikely to change much in the
near future. The overhead seems to have essentially reached its limit ("bolting
readiness on completion") and otherwise the ownership management seems
negligible.
Closes tokio-rs#252
Closes tokio-rs#320
alexcrichton
added a commit
to alexcrichton/mio
that referenced
this issue
Dec 14, 2016
This commit intends to extend the functionality of mio on Windows to support
custom handles being registered with the internal IOCP object. This in turn
should unlock the ability to work with named pipes, filesystem changes, or any
other IOCP-enabled object on Windows. Named pipes are in particular quite
important as they're often a foundational IPC mechanism on Windows.
This support is provided by exporting two new types in a `windows` module. A
`Binding` serves as the ability to register with the actual IOCP port in an
`Evented` implementation. Internally the `Binding` keeps track of what it
was last associated with to implement IOCP semantics. This may one day be
possible to make a zero-sized-type.
The second type, `Overlapped`, is exported as a contract that all overlapped I/O
operations must be executed with this particular type. This ensures that after
an event is received from an IOCP object we know what to do with it. Essentially
this is just a `OVERLAPPED` with a function pointer after it.
Along the way this exposes the `winapi` crate as a public dependency of `mio`.
The `OVERLAPPED_ENTRY` and `OVERLAPPED` types in `winapi` are exposed through
the `Overlapped` type that mio itself exports.
I've implemented [bindings to named pipes][bindings] and I've also got a
proof-of-concept [process management library][tokio-process] using these
bindings. So far it seems that this support in mio is sufficient for building up
these applications, and it all appears to be working so far.
I personally see this as a much bigger committment on the mio side of things
than the Unix implementation. The `EventedFd` type on Unix is quite small and
minimal, but the `Overlapped` and `binding` types on Windows are just
pieces of a larger puzzle when dealing with overlapped operations. Questions
about ownership of I/O objects arise along with the method of handling
completion status notifications. For now this is essentially binding mio to
stick to at least the same strategy for handling IOCP for the 0.6 series. A
major version bump of mio could perhaps change these semantics, but it may be
difficult to do so.
It seems, though, that the Windows semantics are unlikely to change much in the
near future. The overhead seems to have essentially reached its limit ("bolting
readiness on completion") and otherwise the ownership management seems
negligible.
Closes tokio-rs#252
Closes tokio-rs#320
|
For posterity, this support is now available through the |
|
Great, with the help of AppVeyor, the next version of nanomsg will support the ipc transport on Windows too. Thanks ! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Windows offers functionality almost identical to
unix::pipe(),PipeReader,PipeWriter. It would be great if there were cross-platform versions of these.The text was updated successfully, but these errors were encountered: