Use of tokio-file-unix breaks compilation on Windows

[Michael-F-Bryan]

I just tried building tokio-zmq on a Windows machine and it looks like we unconditionally depend on tokio-file-unix, which obviously causes compilation to fail.

How difficult would it be to use platform-specific dependencies in Cargo.toml and then add the necessary #[cfg(unix)] attributes to skip file operations on Windows?

# Cargo.toml

[target.'cfg(unix)'.dependencies]
tokio-file-unix = "0.5"

[asonix]

The file operations are incredibly important to the functioning of this crate. File readiness is how Tokio knows to wake up the zeromq tasks.

Implementating windows support would require finding an alternative to this dependency that works on all platforms (unlikely) or adding a windows-specific dependency, which would be difficult for me to test, since I don't use windows.

I'm not against having windows support, but I can't make any promises right now. If you'd like to try your hand at this, I'd welcome a pull request

[Michael-F-Bryan]

Thanks @asonix, after looking through the source code to see how difficult a PR would be, I had a feeling that was the case.

Is there any reason why you use file readiness for waking up tasks instead of waiting on the socket using the same mechanism as tokio's TcpStream?

[asonix]

I'm not entirely sure how Tokio's TcpStream works, actually, but I'd assume that they have direct access to the operating system socket.

In ZeroMQ, the concept of "sockets" is a little different. ZeroMQ spins up a series of background threads and manages the OS sockets for you, while exposing blocking and nonblocking APIs for interacting with their system. They use "socket" as a term to refer to a single source and/or sink, when really this could be represented underneath as some IPC mechanism, Unix sockets, TCP sockets, UDP sockets, or some combination thereof.

ZeroMQ provides file descriptors that notify on readiness in order to integrate with event loops, which is exactly the purpose of this crate.

[asonix]

@Michael-F-Bryan If you're still interested in an OS-agnostic version of tokio-zmq, I've released futures-zmq, which should be a drop-in replacement for the most recent version of tokio-zmq.

It turns out making this work on windows was remarkably difficult. Mio doesn't provide an EventedFd abstraction for windows, since window's wake semantics are different from unix wake semantics in an incompatible way. I got around this by creating an additional thread in the futures-zmq version that polls the ZeroMQ FD's manually.

The performance is not as great as tokio-zmq, but it should at least work

[asonix]

it's also Executor Agnostic, hence the name 'futures-zmq'