-
Notifications
You must be signed in to change notification settings - Fork 419
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
DaemonThreadFactory creating new Java thread factory each time it creates a new thread #1008
Comments
Thanks for the report. |
Excellent. I'll get started on one. |
@eregon Checking in on this. I recommitted my changes to force a new test run, and everything is green this time. |
Checking in. Please let me know if I can do anything to move this along. The PR is very minimal and should be quick to review. |
@eregon Bumping again |
Merged. Do you need a release? |
Thanks! No urgent need for a release if there's something else in the pipeline that you'd prefer to bundle it with. |
Background Info
concurrent-ruby
version:>= 1.1.10
, earlier versions may be affected as wellconcurrent-ruby-ext
installed: noconcurrent-ruby-edge
used: noIssue
Concurrent::DaemonThreadFactory#newThread
callsdefaultThreadFactory()
each time it generates a new thread, which creates a new JavaThreadFactory
object each time. This is clearly at odds with intendedThreadFactory
usage and is (potentially) problematic in a few ways:pool-X-thread-Y
, where Y is always 1 while X is different for each thread. This is confusing as it suggests that the Concurrent Ruby thread pool is not actually pooling and reusing threads.ThreadFactory
instance is retained somewhere, the result will be a memory leak.ThreadFactory
instance normally belong to the same Java thread group, which has permissions implications and may cause errors in code that expects all the threads in a Concurrent Ruby thread pool to belong to the same Java thread group.Proposed Solution
Call
defaultThreadFactory()
once inConcurrent::DaemonThreadFactory#initialize
, store the resulting factory in an instance variable, and reuse it as needed inConcurrent::DaemonThreadFactory#newThread
.Happy to create a PR with the fix if this seems like an acceptable solution.
The text was updated successfully, but these errors were encountered: