Issue #22098 has been updated by Eregon (Benoit Daloze). Some more context from Claude on `RUBY_INTERNAL_THREAD_EVENT_STARTED`:
Ruby 3.2: STARTED fires in thread_start_func_1 (thread_pthread.c:1166) — this runs on the new thread itself, without the GVL. The new thread hasn't acquired the GVL yet (that happens inside thread_start_func_2). The doc is correct for 3.2.
Ruby 3.3, 3.4, 4.0 (master): STARTED fires in native_thread_create — this runs on the parent thread, with the GVL. The doc is wrong for these versions.
So the behavior changed between 3.2 and 3.3 (with the M:N scheduler work). In 3.2 it was called on the new thread without the GVL as documented; from 3.3 onwards it's called on the parent thread with the GVL.
---------------------------------------- Bug #22098: RUBY_INTERNAL_THREAD_EVENT_RESUMED runs without GVL held https://bugs.ruby-lang.org/issues/22098#change-117686 * Author: luke-gru (Luke Gruber) * Status: Open * Assignee: luke-gru (Luke Gruber) * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- Today, it's possible to get a deadlock when allocating during a hook for this event. I attached a reproduction script using the `gvltools` gem. One way to fix it would be to not allocate during this hook and change the documentation to be clear that the GVL is not held. Any gems relying on this behavior, like `gvltools`, would need to be patched. Another way to approach it would be to change the call site for this hook invocation. I believe it would need to be added to quite a few places. To maintain Ractor safety, it would also need to be invoked without any locks held. I'm curious about your thoughts @byroot. ---Files-------------------------------- repro.rb (3.11 KB) run_loop.sh (2.82 KB) -- https://bugs.ruby-lang.org/