I have a non-blocking TCP socket (for IPC) and a crossbeam-channel (for communication between threads), and I would like to select/poll/epoll/whatever over the socket and the receiving side of the channel simultaneously.
Now I know that this isn't directly possible, because crossbeam-channel doesn't use file descriptors to notify blocked receivers. What would be a good solution to wait on TCP sockets and intra-process channels, preferably one that works on Linux and Windows? It doesn't necessarily have to be crossbeam-channel, but it would be great if I could avoid serialization/deserialization for intra-process communication.
tokio seems to offer non-blocking mpsc channels and sockets, and the ability to wait on a combination of both. How are they doing it?
The way Tokio does it is roughly:
- The thread waiting for the two resources puts itself to sleep using either epoll or kqueue or some other similar api depending on the OS. This works through the mio library.
- This special api will wake the thread up if the socket has an event.
- If someone wants to send the thread a message over the channel, they will tell mio that the thread should no longer be sleeping by notifying it somehow.
Yes, but how? On Linux, I can use eventfd and include that fd in poll() for a relatively high-performance interrupt mechanism. But there's no eventfd on Windows, so would I have to create, e.g., a UDP socket to send 1-byte packets to interrupt the poll() call?
It will use
Registration::new2 to obtain a registration connected to a
SetReadiness, which is registered with the
Poll instance. To wake up the sleeping thread, it uses the
As for windows, mio uses the IOCP api there as far as I know.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.