Smithay
Support for other polling systems than epoll
Well, at the time there was kqueue but we now have it. And mostly I was wondering if we could have some meaningful windows support, or if there are other platforms with different polling systems that we could want to support.
Ah of course, I didn't realise that was added so recently.
I also wondered about Windows. IIRC mostly it's completion based, not readiness based, but obviously some libraries manage it so it must be possible. I might look at how libuv or others do it.
Have you considered using the polling crate? It supports Unixes outside of Linux and the BSDs through a fallback poll() implementation and supports Windows through wepoll.
From a glance over the API, though, the main issues with integration would be that it only supports one-shot polling, although that could be changed. (Except the one-shot one, since wepoll only supports level-triggered and oneshot polling as far as I know.)
@notgull Did you perhaps half-edit this? I don't understand these together:
it only supports one-shot polling, although that could be changed. (Except the one-shot one, since
Also, I keep meaning to comment on this:
And mostly I was wondering if we could have some meaningful windows support
I suspect that if we really wanted that, we'd need to change our epoll()-based approach to io-uring, because Windows only has completion-based async IO (which is what io-uring is).
@detly Sorry, that was half-edited together. At the moment, polling only supports one-shot mode. It could probably also support level-triggered mode, but some of the backends polling uses (namely, the one it uses for Windows) do not support edge triggered operations.
Ah right, that makes sense. For me, edge-triggered mode is important because I use Calloop with ZeroMQ and some Linux hardware APIs (eg. GPIOs) which provide fds that work best with edge-triggering (at least for my uses). I imagine it would be possible to re-write things to use a level-triggered core, but it would not be trivial.
(I keep saying "we", but I'm not a maintainer here by any stretch, just an occasional contributor who uses Calloop for work and hobby projects. @vberger is the authority.)
Hmm... maybe it could be that, if you try to use edge triggered mode on a poller that doesn't support it, it raises an error? I feel like that's the only backwards-compatible way of doing this.
Corresponding issues for polling:
- https://github.com/smol-rs/polling/issues/89
- https://github.com/smol-rs/polling/issues/102
- https://github.com/smol-rs/polling/issues/160
- https://github.com/smol-rs/polling/issues/176
- https://github.com/smol-rs/polling/issues/177
- https://github.com/smol-rs/polling/issues/178
polling supports all Tier 1 and most Tier 2 Rust targets that have a polling system. WASI and UEFI are the only two big holes here. For WASI we're waiting for Preview 2 to come out (see the issue linked above) and for UEFI I'm not familiar enough with the spec to know if there even is a way to poll multiple streams at once (I forget if UEFI even has networking in the first place). There are a couple of other oddballs (Redox, FortanixOS) but aside from that the main bottleneck is implementing Ping support in calloop.