selector/io-select using threads to wait

[shyamalshukla]

With fiber scheduler support in ruby 3.2 and above, schedulers like async rely io-events implementation of io-select (and other methods). Io-select does not take in the calling fiber parameter (like other methods such as io-wait, io-read etc), and also falls back to a new thread to wait for IOs. Wouldn't this defeat the purpose of setting up an event loop and cause the thread to block?

https://github.com/socketry/io-event/blob/main/lib/io/event/selector/select.rb#L170

[ioquatix]

In general, it is extremely hard to emulate select() correctly using an event loop. Some code uses IO.select([io]) instead of io.wait_readable for example. We could probably detect these degenerate cases and issue warnings/rewrite the operation to wait_readable or wait_writable. But generally, running the operation on a background thread prevents a naive implementation of select() from stalling the event loop.

You are correct, the fiber is not passed in as the first argument. That is a small interface oversight which we could fix by checking the arity of the method.

Alternatively, blocking_operation_wait is a more generic interface for handling these types of problems, using a thread pool, but I have not optimised this case as it's not particularly common.

[shyamalshukla]

Would translating an io-select into a sequence of io-wait be a good way of adding support?

IO.select seems like a common operation extensively used in many libraries, and lack of support for which leaves no options of making them a part of the event loop, but use Threads for such IO activity.
Running the operation on a new background thread (within io-select) for each call that is made to IO.select from the higher level library, would be as good as creating a thread from the higher level library?