The following program seems to work okay on Ruby 3.2 but hangs on Ruby 3.3:
#!/usr/bin/env rubyrequire'bundler/inline'gemfiledosource'https://rubygems.org'gem'async'endrequire'socket'defclose_while_reading(io)thread=Thread.newdoThread.current.report_on_exception=falseio.wait_readableend# Wait until the thread is blocked on read:Thread.passuntilthread.status=="sleep"Asyncdoio.closeendthread.joinendbeginclient,server=Socket.pair(:UNIX,:STREAM)close_while_reading(client)rescue=>error$stderr.putserror.full_messageend
Sorry about this. I think https://github.com/ruby/ruby/pull/11614 is the smallest diff that will fix the issue (and this should probably be backported to 3.3).
Separately to that, I wonder if we need to wrap up some common function for "wake up this fiber, either with the fiber scheduler or with the thread directly". We've implemented this logic in a number of places... but let's keep that refactor out of the fix PR (since it shouldn't be backported).
Ensure fiber scheduler is woken up when close interrupts read
If one thread is reading and another closes that socket, the close
blocks waiting for the read to abort cleanly. This ensures that Ruby is
totally done with the file descriptor BEFORE we tell the OS to close
and potentially re-use it.
When the read is correctly terminated, the close should be unblocked.
That currently works if closing is happening on a thread, but if it's
happening on a fiber with a fiber scheduler, it does NOT work.
This patch ensures that if the close happened in a fiber scheduled
thread, that the scheduler is notified that the fiber is unblocked.