Issue #22098 has been updated by jhawthorn (John Hawthorn). Here's a reproduction showing that `ruby_thread_has_gvl_p()` is false https://github.com/ruby/ruby/pull/17263. I think it has been since the introduction of the callback. I think it might be fine for `ruby_thread_has_gvl_p()` to return false (we could adjust the documentation to say "about to acquire the GVL" or "has exclusive hold on the GVL, but hasn't yet fully acquired it"). But I think the bigger question is **are we allowed to allocate in this callback**? Doing so seems broken today and I also don't think it should be allowed. ---------------------------------------- Bug #22098: THREAD_EVENT_RESUMED runs without GVL held https://bugs.ruby-lang.org/issues/22098#change-117527 * 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/