From: "jhawthorn (John Hawthorn) via ruby-core" Date: 2026-06-12T01:59:28+00:00 Subject: [ruby-core:125715] [Ruby Bug#22098] RUBY_INTERNAL_THREAD_EVENT_RESUMED runs without GVL held Issue #22098 has been updated by jhawthorn (John Hawthorn). Eregon (Benoit Daloze) wrote in #note-13: > "you can not use any Ruby APIs" is too strict, at minimum we need: > * rb_internal_thread_specific_get()/rb_internal_thread_specific_set() > * rb_postponed_job_trigger() These are all documented to be async-signal-safe, and so can be called everywhere (including the existing hooks with the quoted restriction). I don't think that needs clarification here, but we could spell it out I guess. > * TypedData_Get_Struct() Should not be explicitly supported as it can raise an exception (though I'm sure it doesn't in your use) and so runs arbitrary user code. `RTYPEDDATA_GET_DATA` is probably fine, but unlike the async-signal-safe examples doesn't feel like the type that should be explicitly allowed here or in the internal GC hooks. Why do you need it? Could you pass the raw pointer? > If we forbid APIs like allocation, would it be possibly to reliably fail if called from these hooks with a RUBY_DEBUG build? > That'd be a good way to validate it (which we could even document on `rb_internal_thread_add_event_hook()`). I'd love to add [`ASSERT(ruby_thread_has_gvl_p()) to newobj`](https://github.com/ruby/ruby/pull/17289) (and maybe to `rb_funcall`), but I don't know if the performance is acceptable even for debug builds. ---------------------------------------- Bug #22098: RUBY_INTERNAL_THREAD_EVENT_RESUMED runs without GVL held https://bugs.ruby-lang.org/issues/22098#change-117580 * 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/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/