Support disjoint polls on separate threads

[kskalski]

Main page states "Only one thread can be waiting for I/O events at a time.", but it's not clear what is the scope of this limitation.

Does it mean:

• sharing the same Poller object across threads and waiting in both is not supported
• using two different Poller objects and waiting on them in different threads
  • on the same fd won't work
  • on different unique fd in each of the pollers / threads also won't work?

My use-case it the last one, which seems to be a bit weird not to be supported unless the library uses a process-wide shared lock for some reason.

[fogti]

I think "on different unique fd in each of the pollers / threads also won't work?" should usually work, but might not work on some OS supported by polling.

[notgull]

Using the same Poller on two threads will fail. Using different Pollers to poll the same file can lead to events being lost. See this documentation on the add() function:

It is possible to register interest in the same file descriptor or socket using multiple separate Poller instances. When the event is delivered, one or more Pollers are notified with that event. The exact number of Pollers notified depends on the underlying platform. When registering multiple sources into one event, the user should be careful to accommodate for events lost to other pollers.

One may also register one source into other, non-polling event loops, like GLib’s context. While the plumbing will vary from platform to platform, in general the Poller will act as if the source was registered with another Poller, with the same caveats as above.