fix: Provide thread names whenever possible #316
Merged
+30
−13
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
Related issues
There are no related issues at the time of filing.
Describe the solution you've provided
At @speedshop we have a client that uses LaunchDarkly. One thing we noticed was that the Ruby SDK relies on the
Thread
very extensively, either directly or through theconcurrent-ruby
gem. As a result of this, a number of threads will be created after the first call to LD:This is all expected, and normally this is fine. In some specific circumstances where a deep dive into e.g. performance of each thread is required, not having a thread name could possibly lead to a longer investigation. For example, the
gvl-tracing
gem generates Perfetto profiling results for each thread, that looks like this:The red arrow points to
Thread 11
, which is not obvious as to who created it, what it's used for, etc. Compare that with the thread name of"puma srv tp 001 from puma 1"
above, which makes it very clear that it's a worker thread within a Puma instance.This PR updates the code that creates threads to also assign a name to them. After this PR the result of the Perfetto visualization could look like this:
As you can see, now this is a lot easier to understand who owns this thread. Because of the nature of the thread where we don't know exactly when they are created or GC-ed, I believe it is also important to assign thread names whenever possible, so they will show up with a clear name in a profiling result like above.
Describe alternatives you've considered
The thread name itself is quite primitive enough that there is no other alternative here. Other good citizens like the
debug
gem, ActiveRecord, Puma all provide thread names, so I believe it is good practice to follow in general.Additional context
The
Concurrent::TimerTask
class fromconcurrent-ruby
, used in theEventProcessor
class:ruby-server-sdk/lib/ldclient-rb/events.rb
Line 121 in 39b1e0e
ruby-server-sdk/lib/ldclient-rb/events.rb
Line 125 in 39b1e0e
ruby-server-sdk/lib/ldclient-rb/events.rb
Line 133 in 39b1e0e
also creates threads internally. Unfortunately it ignores the
name
option and there is no way for us to set a name at least today, so I left it unchanged for now.