Issue #19440 has been updated by Eregon (Benoit Daloze). mame (Yusuke Endoh) wrote in #note-3:
#19020 explained only the phenomenon, but didn't explain how the problem is troubling in a real program. Assuming that the problem is to pollute the ThreadGroup to which the calling Thread belongs, @nobu suggested timeout.rb to create a dedicated ThreadGroup and to make its timer thread belong there (as follows), instead of making the thread belong to ThreadGroup::DEFAULT.
``` -ThreadGroup::Default.add(watcher) +ThreadGroup.new.add(watcher) ```
This would not work. Because `ThreadGroup.new.add(watcher)` will fail due to the timeout Thread being created initially in the airbrake's enclosed ThreadGroup. So currently there is no way to put the the Timeout thread in the correct group. ---------------------------------------- Feature #19440: Deprecate ThreadGroup https://bugs.ruby-lang.org/issues/19440#change-102366 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal ---------------------------------------- I looked at the ThreadGroup methods, and none of them seem really useful. `enclose` has super confusing semantics, in that it surprisingly allows creating new threads from a thread already in that group, but forbids `#add`. So the new thread is not the same as "adding" a thread, very confusing. This weird restriction results for instance in `Timeout` not being able to move the Thread it creates to the default ThreadGroup: https://github.com/ruby/timeout/issues/24 And there is also no method to create a Thread in the given ThreadGroup. `add` and `list` could just be simulated with an Array. Maybe it's time we deprecate ThreadGroup or at least `enclose`/`enclosed?` since those seem to have unusable/useless semantics? If not, how do we cleanly solve https://github.com/ruby/timeout/issues/24? -- https://bugs.ruby-lang.org/