Thanks, that makes sense, and sorry for batching the two fixes. byroot dropped the commit for extensions that call `fork(2)` from https://github.com/ruby/ruby/pull/19364 before merging it, so the PR fixed only #22445. 🙇♂️dug (Doug E)
While preparing the backports I found one kind of child that still inherits the slot of exiting lookup threads: a child that an extension forks with `fork(2)` and then passes to `rb_thread_atfork()`, as the C API asks. `rb_thread_acquire...dug (Doug E)
On macOS, `Kernel#fork` can abort the child with `[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)` when another thread is waiting for the fork lock at the moment of the fork. getaddrinfo helper threads take that lock for reading (Fea...dug (Doug E)
@mame @byroot @ko1 Thank you for the time you've given this ticket, and for the thoughtful feedback here and on the pull requests. https://github.com/ruby/ruby/pull/19242 now uses a single slot, as @byroot and Luke Gruber suggested on...dug (Doug E)
@ko1 Thank you for checking getnameinfo, and you're right that it belongs here. I've added it to https://github.com/ruby/ruby/pull/19242: * The getnameinfo thread now runs within `rb_thread_prevent_fork`, is created joinable and calls...dug (Doug E)
I opened https://github.com/ruby/ruby/pull/19267, which removes the assertion as suggested in #note-1. Debug builds now raise `TypeError` ("uninitialized class") like release builds do, and there's a regression test in `TestClass#test_un...dug (Doug E)
dug (Doug E)07:16 PM Ruby Bug #22406: Process.fork can leave the child unable to resolve hostnames: getaddrinfo helper threads take glibc's resolver lock after releasing the fork lock