Issue #22098 has been updated by luke-gru (Luke Gruber). Yes, this has always been buggy and I also don't think we should allow allocating objects/xmalloc in the hook. Even if we changed `ruby_thread_has_gvl_p()`, the problem is that this hook runs with the scheduler lock held (and always has). We would have to move the invocation of the hook outside of any locks, so it would need to be copied to many call sites (~10). Otherwise, under Ractors, a different type of deadlock could occur if the hook caused a GC and another Ractor was blocked on this Ractor's scheduler lock (it wouldn't be able to join the VM barrier). ---------------------------------------- Bug #22098: THREAD_EVENT_RESUMED runs without GVL held https://bugs.ruby-lang.org/issues/22098#change-117530 * 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/