Waker does not support Interest::WRITABLE

[alexforster]

I do not believe that the removal of Registration/SetReadiness functionality in #907 can be completely replaced by Waker without the ability to signal both Interest::READABLE and Interest::WRITABLE.

Using 0.6, I was able to implement something equivalent to a Linux veth pair using two SPSC queues and the following logic–

fn update_readiness(&mut self) {
    let mut local_readiness = mio::Ready::empty();
    let mut remote_readiness = mio::Ready::empty();

    if !self.rx_buffer.is_empty() {
        local_readiness |= mio::Ready::readable();
    }
    if !self.rx_buffer.is_full() {
        remote_readiness |= mio::Ready::writable();
    }

    if !self.tx_buffer.is_full() {
        local_readiness |= mio::Ready::writable();
    }
    if !self.tx_buffer.is_empty() {
        remote_readiness |= mio::Ready::readable();
    }

    if self.local_readiness.readiness() != local_readiness {
        self.local_readiness.set_readiness(local_readiness).ok();
    }
    if self.remote_readiness.readiness() != remote_readiness {
        self.remote_readiness.set_readiness(remote_readiness).ok();
    }
}

[Thomasdezeeuw]

Waker isn't designed as a replacement for Registration/SetReadiness, its only goal it to wake a thread calling Poll::poll. Registration/SetReadiness was implemented as queue of events in user space, something considered out of scope for Mio 0.7, which focusses on providing a platform abstraction around kqueue/epoll.

How to replace your functionality depends on what you where doing with it. If you we're using two threads (one for the sending and and one for the receiving), you can create a Poll and Waker instance on both threads. Then you can share the Waker with the other end and call Waker::wake when sending/receiving a message on the channel, i.e. call the receiver's Waker when sending a message. Once you get an Event with the Token the Waker was registered with you know you can send into or receive from the channel.

If you're using a single thread or don't use dedicated threads for the channel you'll have to implement something in user space yourself to determine when you can send into or receive from the channel, but this outside of the scope for Mio.

[alexforster]

The reason that I use mio is the ability to implement I/O polling semantics on arbitrary things in a unified way – often these things aren't actually OS file descriptors. Wasn't that the whole point of this library? Changing the whole point in a minor release of the 73rd most used crate seems pretty unfair to your users.

[Thomasdezeeuw]

The reason that I use mio is the ability to implement I/O polling semantics on arbitrary things in a unified way – often these things aren't actually OS file descriptors. Wasn't that the whole point of this library?

I don't believe it was. Most people were using different implementations for user space events already. For v0.7 we decided to focus the crate to make a push for v1.

Changing the whole point in a minor release of the 73rd most used crate seems pretty unfair to your users.

Before v1, 0.x isn't a minor release, but a major (and possibly breaking) one. But I see your point, that is why I've tried helping people migrate to v0.7 as much a people (feel free to look through the issues).

[Thomasdezeeuw]

I don't see anytime actionable here, so I'm closing.