Support for other polling systems than epoll

[elinorbgr]

To be added in the sys module.

[detly]

Any in particular you had in mind?

[elinorbgr]

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]

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]

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]

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

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]

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

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]

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]

Corresponding issues for polling:

• Support the AIX operating system smol-rs/polling#89
• WASI support? smol-rs/polling#102
• Add support for PS Vita smol-rs/polling#160
• RedoxOS Support smol-rs/polling#176
• HermitOS Support smol-rs/polling#177
• FortanixOS Support smol-rs/polling#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.