-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving Threads to Threadgroup::Default should not happen for enclosed ThreadGroups #24
Comments
I think this shows Ruby should really support creating a Thread in a different ThreadGroup than the caller's thread's group, so we could create the timeout thread directly in the default ThreadGroup (or with its own ThreadGroup or no ThreadGroup if that was possible) It's quite wrong that the Timeout thread stays in the airbrake ThreadGroup as with your suggested change. Part of this is why does airbrake use
I get this is an annoying failure, which also depends on what uses |
I totally agree with that. Creating a thread in specific ThreadGroup is the best solution. You could have a timer group for example. I’ve already opened the issue at Airbrake, I tried tot dive in deeper and found the cause of it, in this Timer class. I hope Ruby improves the support for creating threads in a specific group. Why airbrake encloses it, I don't know. I don’t think it’s very useful there. |
The proposed change could be a fix/workaround for other libraries which are experiencing strange issues. Net::Http uses this Timer, which makes the library useless in enclosed Threads. (Whatever reasons the authors had to enclose the threads). (This change was added to Net::Http, October last year, so suddenly the library is broken) Btw I really don't think it's strange those timers are kept in the enclosed group. It's the place where the timers have been created. They cannot, perhaps should not 'escape' the group. |
Right, the workaround seems the best we can do for existing Ruby releases, besides airbrake/gems not using |
I'm the author of the code in question. The code has been there for quite some time, and if I am not mistaken, it's there just to ensure that we do not accidentally add more worker threads to the thread group because the library has an option that specifies how many workers it should spawn. I inspected the current code of the airbrake gem and it seems like we can safely remove the
Could you please show me where the docs say it's not well-supported? I am checking ruby-doc.org but I cannot see any mentions of the API being unstable or poorly defined.
I know nothing about the implementation of the timeout library, but I am curious, why does it need to call |
Currently I'm writing the PR. The reason for this, is that the Timeout thread was already created outside the enclosed thread group, by the other test-cases. In irb no timeouts had been started yet. So another workaround for libraries is to ensure the thread is created before starting any Timeouts. See remark of @eregon in next message, method above is an internal api. Better to just start a timeout, to ensure the thread is created Timeout.timeout(0.001) {} # Use > 0 as timeout value, or it will not start the thread |
Note this method should be considered private API (the only public API is |
@kyrylo Thank you for the reply.
Right, this is my interpretation of it. And then the lack of API to create a Thread directly in a ThreadGroup seems a big oversight, it's inconvenient and racy to move it only after it's created. |
Thanks for the response, @eregon. I can see now why it's poorly defined. |
This should probably be put to koichi-san's attention since he kind of oversees a lot of the thread-related aspects in ruby (e. g. the whole ractor model), if the code is old such as 2006 or even older. |
Moving the Thread to ThreadGroup::Default causes issues with enclosed ThreadGroups. (this change happend in commit c4f1385)
It goes wrong in for example the airbrake-ruby gem. (airbrake/airbrake-ruby#713 (comment))
This problem could be solved by making
lib/timeout.rb:123
conditionalExample to illustrate this behavior:
The text was updated successfully, but these errors were encountered: