Closed keepsimple1 closed 1 year ago
There is other precedent for making Event
an opaque structure that has other platform specific info, see #112. In addition to fact that we need to make a breaking change soon (#38), I would be partial to exposing other epoll
flags on the Event
type.
However, we should also consider if such an abstraction should be exposed on other platforms. kqueue
and poll
, for instance. If so, would there be a cross-platform way of doing it?
However, we should also consider if such an abstraction should be exposed on other platforms.
kqueue
andpoll
, for instance. If so, would there be a cross-platform way of doing it?
In poll
, there is POLLPRI
that is equivalent to EPOLLPRI
in epoll. I'm not sure about kqueue
. I was wondering, maybe Priority data
is general enough to be a cross-platform thing? If yes, then maybe Event
can provide an API to indicate an interest in priority data only?
kqueue
's priority mechanism seems to be platform-specific. DragonBSD and OpenBSD seem to have the EVFILT_EXCEPT
filter which is combined with the NOTE_OOB
filter flag, but FreeBSD does not appear to support this. macOS may support it, but I'm not certain, and it has its own mechanism via the EV_OOBAND
flag on the read filter. (Note that all of this is gleaned from searches and I haven't tested any of it, so it should be taken with a grain of salt.)
However, we should also consider if such an abstraction should be exposed on other platforms. kqueue and poll, for instance. If so, would there be a cross-platform way of doing it?
Extension traits is what you can do, it's common in winit, so you should be familiar.
Extension traits is what you can do, it's common in winit, so you should be familiar.
When possible, I generally prefer exposing a cross-platform abstraction. Something like this would definitely be possible for event ports and Windows; unfortunately it looks like kqueue
is the odd one out here.
As of #133 it is now possible to wait on HUP and PRI specifically.
well, it still isn't possible to remove IN
from the flags, even with that PR merged...
You can do this to only select PRI events:
Event::none(key).with_pri()
https://github.com/smol-rs/polling/blob/e2129ea87933609da994e354f68cc4256726c15f/src/epoll.rs#L277
I'm trying to use this crate to poll GPIO interrupt in Linux (Raspberry Pi 4) via
/sys/class/gpio/
. But asread_flags
above always includeEpoll::IN
, it always return a readable event for the exported gpio file (i.e./sys/class/gpio/gpioN/value
) , and hence cannot detect the interrupt.In my testing, removing
Epoll::IN
(or only useEpoll::PRI
) fixes this case and enables the poller detects the GPIO interrupt. However, the current poller.add()
API does not accept custom read flags. I'm wondering if such issue has been considered before, and is there any plans to support custom read flags for epoll?