mio: Reduce Mio's portable API to only support edge triggered notifications (no oneshot).

As far as I know, when used as a portable API, Mio is only used with edge triggered notifications. Additionally, Mio’s support for portable oneshot notifications is incorrect.

Given this, I propose reducing Mio’s portable API to simply support edge triggered notifications. Roughly (not factoring in all planned changes), Evented would be updated to:

pub trait Evented {

    fn register(
        &mut self, 
        register: &mut Register, 
        token: Token, 
        interests: Interests
    ) -> Result<()>;

    fn deregister(&mut self, register: &mut Register) -> Result<()>;
}

We could possibly keep a PollOption around for forwards compatibility.

Notably, it is no longer possible to change the interest after initial registration without deregistering first.

It would be possible to add platform specific APIs to access the other poll modes, but those would not be done via the Evented trait.

Thoughts?

cc/ @asomers @Thomasdezeeuw @stjepang

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 1
Comments: 23 (10 by maintainers)

Most upvoted comments

@0xpr03 I’ve read through https://github.com/notify-rs/notify/pull/278 and I think it’s doing the right thing. The loop at https://github.com/notify-rs/notify/pull/278/files#diff-b38928aaabe2c7f4a3272295a3c8bb05873ab22a7275c330934cd4a0da1d5de5R206 should ensure that all events are read and that new ionotify events generate new Mio events. Is there a regression test for https://github.com/notify-rs/notify/issues/267 somewhere? Because I think it would pass it.

Thomasdezeeuw on Jan 26, 2021

@rom1v I can take a look at your code to see how hard it is to use edge triggers. As for the discussion it was public on Gitter, likely around the same time I made that comment.

Thomasdezeeuw on Jul 10, 2019