Issue #22098 has been updated by Eregon (Benoit Daloze). As I wrote in https://github.com/Shopify/gvltools/pull/34#issuecomment-4667841039, my expectation is also that this hook is called with the GVL, on the thread which just acquired the GVL. I think not being to allocate is not the end (maybe already a requirement for this hook in previous releases?), but it sure would be nice if it was. Since the hook is called after the GVL is acquired, one would expect to be able to run regular Ruby code there. However as you say the scheduler lock is held and so one should use a `postponed_job` for now like [here](https://github.com/DataDog/dd-trace-rb/blob/b75cf221d321bfea448ede1349c108a8...) (we should document that). Being able to do more in that hook would simplify things quite a bit, I actually [tried that last week](https://github.com/DataDog/dd-trace-rb/pull/5865) by coincidence but eventually found about the undocumented fact that it runs with the scheduler lock held and so probably not a good idea. FWIW `RB_INTERNAL_THREAD_HOOK(RUBY_INTERNAL_THREAD_EVENT_SUSPENDED, th);` is currently called in 6 places, so having it in 10 callers sure feels not so nice but there is also precedent, and maybe something that could be refactored. FWIW in Ruby 3.2 there were actually much fewer `RB_INTERNAL_THREAD_HOOK()` call sites, maybe the new scheduler is still "taking shape"? ---------------------------------------- Bug #22098: THREAD_EVENT_RESUMED runs without GVL held https://bugs.ruby-lang.org/issues/22098#change-117533 * 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/