search

Smithay / calloop

A callback-based Event Loop
MIT License
177 stars 35 forks source link

Support for other polling systems than epoll #14

Open elinorbgr opened 4 years ago

elinorbgr commented 4 years ago

To be added in the sys module.

detly commented 2 years ago

Any in particular you had in mind?

elinorbgr commented 2 years ago

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.

detly commented 2 years ago

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.

notgull commented 1 year ago

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.)

detly commented 1 year ago

@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

detly commented 1 year ago

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).

notgull commented 1 year ago

@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.

detly commented 1 year ago

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.)

notgull commented 1 year ago

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.

notgull commented 9 months ago

Corresponding issues for polling:

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.