-
Notifications
You must be signed in to change notification settings - Fork 419
Open
Description
Background Info
- Ruby implementation: JRuby
concurrent-rubyversion:>= 1.1.10, earlier versions may be affected as wellconcurrent-ruby-extinstalled: noconcurrent-ruby-edgeused: no
Issue
Concurrent::DaemonThreadFactory#newThread calls defaultThreadFactory() each time it generates a new thread, which creates a new Java ThreadFactory object each time. This is clearly at odds with intended ThreadFactory usage and is (potentially) problematic in a few ways:
- It leads to thread names of the form
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. - This does not seem to be happening in the Concurrent Ruby code, but if a reference to each
ThreadFactoryinstance is retained somewhere, the result will be a memory leak. - Threads created by a
ThreadFactoryinstance 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 in Concurrent::DaemonThreadFactory#initialize, store the resulting factory in an instance variable, and reuse it as needed in Concurrent::DaemonThreadFactory#newThread.
Happy to create a PR with the fix if this seems like an acceptable solution.
Metadata
Metadata
Assignees
Labels
No labels