Issue #22098 has been updated by Eregon (Benoit Daloze). jhawthorn (John Hawthorn) wrote in #note-7:
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"
This sounds pretty weird (to me at least) because intuitively, either you (a thread) have a lock (i.e. you are its sole owner and won a compare-and-swap or so), or you don't and can't know when you'll get it (depends on another thread releasing it and this thread winning the race to acquire it). Interesting that `ruby_thread_has_gvl_p()` is false, but I think it's something to fix, not to make even harder to use :sweat: ---------------------------------------- Bug #22098: THREAD_EVENT_RESUMED runs without GVL held https://bugs.ruby-lang.org/issues/22098#change-117534 * 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/