GeezerVison

A zero-timeout IO.select registered every channel with a pooled
selector, polled it, then cancelled the keys and polled again to flush
them before returning the selector. io-event's select backend makes
this call on every turn of the event loop.

A zero timeout cannot block, so none of that registration is needed to
keep it interruptible. When native support is on and every IO has a
real, selectable descriptor, check them with poll(2) directly, falling
back to the selectors otherwise. Buffered read data still counts as
ready, and a socket with a connect in progress goes to the selectors,
which finish the connect once it is writable. Readiness is collected
per descriptor because macOS reports a descriptor that appears twice
in only one of its pollfds.

IO.select([r], [w], nil, 0) on a pipe, on an M1 Pro, drops from 14.8us
to 1.0us per call, about 14 times faster; MRI 4.0 takes 1.2us.

The POLL* values are the ones Linux, macOS, the BSDs and Solaris share;
other systems, such as AIX, keep using the selectors.

The poll path took the array sizes once, so a #to_io that shrinks the
array it was found in made it read past the end and raise TypeError,
where the selectors and MRI return nil. Poll over copies instead.

The except array is now checked after the read and write arrays and
for its write IO as well, as selectInternal and MRI's select_internal
do, and the struct pollfd fields get named offsets.

The pollfds buffer is kept per thread, so a #to_io that runs another
zero-timeout IO.select overwrote the entries already filled in, and
the outer select could miss a ready IO. Collect the descriptors first
and fill the buffer just before poll(2), once no Ruby code can run.

PollSelect itself is only loaded on the first zero-timeout select, so a
holder class makes the loading no lazier.

headius left a comment