Support for using poll as a backend

[Janrupf]

Tracking issue for #1602

See PR for a full technical description.

---

This is tracking the integration of a mio backend using the poll(2) syscall for Unix like OS that don't support epoll or kqueue.

Technically this can target every OS which supports the poll (or even select syscall).

[Janrupf]

I found something which probably needs change in the documentation in order for this to land, see here:

mio/src/poll.rs

Lines 89 to 96 in 3340f6d

	/// ### Draining readiness
	///
	/// Once a readiness event is received, the corresponding operation must be
	/// performed repeatedly until it returns [`WouldBlock`]. Unless this is done,
	/// there is no guarantee that another readiness event will be delivered, even
	/// if further data is received for the event source.
	///
	/// [`WouldBlock`]: std::io::ErrorKind::WouldBlock

In my PR I commented that this might be a breaking change, but reading this it may actually not be one. With the poll backend, readiness events are delivered constantly until a source is fully drained. This means the comment maybe should be extended to say

Furthermore, on some systems events may be continuously delivered until all data is consumed. 

[notgull]

As I said before I support this, since it would go a long way to making mio and thus tokio compatible on all platforms. This would also probably serve as a foundation to add true WASI support once a polling mechanism is added to it

[Thomasdezeeuw]

We haven't defined our policy properly yet (that's #853), but I would like to know at least the following before we can even start with the code.

1. Which platforms/OSs are going to use this?
2. Who's going to maintain this? Are people willing to commit to that?
3. What does the CI for this look like?

[Janrupf]

1. Which platforms are going to use this?

Any Unix (POSIX?) like platform with poll support but no epoll - in general, this question is a bit tricky to answer. Probably everything which currently does not run due to missing epoll support.

Systems that are so far known:

• Haiku
• Espressif devices (espidf platform)
• Nintendo 3DS (probably?)

I assume those to actually be mostly embedded platforms.

2. Who is going to maintain it?

Again a bit tricky to answer - while I expect this to not require too many changes (famous last words) I agree that someone needs to maintain it going forward. The positive side is that this can be tested on any Unix platform, so everyone who is using Linux can test and develop this selector.

I also expect the esp-rs community to pick this up once it gets merged, which would mean people start using it more frequently. Maybe it can be marked as an experimental backend for now (requires coordination with tokio) as to warn people.

Overall, I am willing to maintain this implementation - I am already using it in my personal as well as work projects.

3. CI

Testing the implementation is not too hard provided you do that on a Linux system. The CI step would be a build with the force-old-poll feature enabled, then running the tests. Additionally, this could also be run on MacOS and FreeBSD, those systems have the poll API as well.

Testing it on the embedded systems is not really possible, however, these usually commit to a POSIX compatible API when providing poll.

[notgull]

Which platforms/OSs are going to use this?

ESP-IDF and Fuchisia are the two big-ticket platforms that would take advantage of this, although any Unix-like systems without a scalable polling system, like Haiku or Horizon, would also use this.

Who's going to maintain this? Are people willing to commit to that?

I could help maintain this.

What does the CI for this look like?

You could force the old poll syscall on Linux. You could also use cargo cross to test on BSD and the like.

[Thomasdezeeuw]

@Janrupf

1. Which platforms are going to use this?

Any Unix (POSIX?) like platform with poll support but no epoll - in general, this question is a bit tricky to answer. Probably everything which currently does not run due to missing epoll support.

Systems that are so far known:

* Haiku
* Espressif devices (espidf platform)
* Nintendo 3DS (probably?)

I assume those to actually be mostly embedded platforms.

This is a little bit vague, but we can start with Haiku and expand from their.

2. Who is going to maintain it?

Again a bit tricky to answer - while I expect this to not require too many changes (famous last words) I agree that someone needs to maintain it going forward.

I highly doubt this, that's what it always looks the first time ;)

The positive side is that this can be tested on any Unix platform, so everyone who is using Linux can test and develop this selector.

I don't want to support poll on Linux, we have epoll for that already. We need concrete use cases, not theoretical ones.

I also expect the esp-rs community to pick this up once it gets merged, which would mean people start using it more frequently. Maybe it can be marked as an experimental backend for now (requires coordination with tokio) as to warn people.

I'm afraid I need more concrete commitment than this.

Overall, I am willing to maintain this implementation - I am already using it in my personal as well as work projects.

This is good start.

3. CI

Testing the implementation is not too hard provided you do that on a Linux system. The CI step would be a build with the force-old-poll feature enabled, then running the tests. Additionally, this could also be run on MacOS and FreeBSD, those systems have the poll API as well.

I don't want any features for this, just support for OSs that don't support kqueue/epoll. This also means that we need concrete OSs to test this with, not an OS/poll combination that's never going to be used.

Testing it on the embedded systems is not really possible, however, these usually commit to a POSIX compatible API when providing poll.

Concrete implementations often have bugs and/or differences between the implementation and the spec, but we can put embedded (none-Linux) systems in an experiment tier.

@notgull

Which platforms/OSs are going to use this?

ESP-IDF and Fuchisia are the two big-ticket platforms that would take advantage of this, although any Unix-like systems without a scalable polling system, like Haiku or Horizon, would also use this.

Fuchsia is working on or has Linux capability and should work with epoll, but we have no-one to maintain the port (that's why the previous one was removed).

Who's going to maintain this? Are people willing to commit to that?

I could help maintain this.

👍

What does the CI for this look like?

You could force the old poll syscall on Linux. You could also use cargo cross to test on BSD and the like.

See above, but testing this on OSs that have a different poll implementation isn't going to work.

[Janrupf]

I'm not entirely sure where to start with CI, I couldn't find a CI solution which would allow to test on Haiku.

(The only OS that I were able to test this on are Linux and the espidf)

[Janrupf]

Alright, I think its time for some progress updates:
I have found a possible CI solution using Vagrant and MacOS Github runners (apparently they have nested virtualization enabled).

The somewhat bad news is: I now need to also port mio to HaikuOS, because, well, its needed for testing. However, this doesn't seem too different from what I have done to get mio to work on the espidf.

[Thomasdezeeuw]

Alright, I think its time for some progress updates: I have found a possible CI solution using Vagrant and MacOS Github runners (apparently they have nested virtualization enabled).

Would qemu have lower overhead? We don't want to slow down the CI too much.

[Janrupf]

Vagrant will be using Virtual Box on MacOS - I think this is the fastest solution, since it is the only one actually having nested virtualization on Github runners.

[Janrupf]

I'm also running into a few tests which are now failing because they rely on file descriptors being removed automatically when they are closed.

With poll this is not the case, you may receive events after closing a file descriptor if you don't properly deregister it. I've stated that already in the PR description, but I have the very strong feeling that this will qualify as a breaking change.

EDIT: I think I have found a solution for this issue, very similar to what the windows implementation does already. It will take some time to implement it, but basically it saves the current registry in the IoSourceState. This should also allow proper edge based polling emulation.