[PROF-7440] Add fallback name/invoke location for unnamed threads started in native code #2993
Conversation
…rted in native code **What does this PR do?**: This PR adds a fallback invoke location (which gets used as a name) for threads that a) Are unnamed, and b) Were started from native code. The added invoke location is the fixed string `(Unnamed thread from native gem)`. **Motivation**: We previously (in #2950) started using invoke location for threads that do not have a name BUT when a thread is started from native code it would have an empty name. Having an empty name is not particularly helpful, so I decided to instead have a simple placeholder that at least provides an hint on what the thread may be. **Additional Notes**: We don't yet do any resolving of symbols from native code, but in the future I guess we may try to see if the native code has a name at the C level, and use that as a fallback, but that's much more than a one-liner change :) **How to test the change?**: Change includes code coverage.
Codecov Report
@@ Coverage Diff @@
## master #2993 +/- ##
==========================================
- Coverage 98.09% 98.09% -0.01%
==========================================
Files 1305 1305
Lines 72731 72736 +5
Branches 3366 3366
==========================================
+ Hits 71345 71348 +3
- Misses 1386 1388 +2
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
| // If the first function of a thread is native code, there won't be an invoke location, so we use this fallback. | ||
| // NOTE: In the future, I wonder if we could take the pointer to the native function, and try to see if there's a native | ||
| // symbol attached to it. | ||
| snprintf(thread_context->thread_invoke_location, THREAD_INVOKE_LOCATION_LIMIT_CHARS, "%s", "(Unnamed thread from native gem)"); |
There was a problem hiding this comment.
Is it always a thread from a "gem"? Could this thread have originated from the current application's native code?
There was a problem hiding this comment.
You know what, your question gave me quite a bit of pause.
This being Ruby, the answer is of course "everything is possible", but then I started thinking it would be kinda awkward it would be, since you wouldn't get the automatic compilation behavior on install like you get for gems. On the other hand, I can imagine if you need to interact with some weird hardware (like for a point of sale), you may end up doing that anyway.
In the end, as we already had another placeholder "In native code", I changed this one to be (Unnamed thread from native code) to match it in c52c732 .
What does this PR do?:
This PR adds a fallback invoke location (which gets used as a name) for threads that a) Are unnamed, and b) Were started from native code.
The added invoke location is the fixed string
(Unnamed thread from native gem)(Unnamed thread from native code).Motivation:
We previously (in #2950) started using invoke location for threads that do not have a name BUT when a thread is started from native code it would have an empty name.
Having an empty name is not particularly helpful, so I decided to instead have a simple placeholder that at least provides an hint on what the thread may be.
Additional Notes:
We don't yet do any resolving of symbols from native code, but in the future I guess we may try to see if the native code has a name at the C level, and use that as a fallback, but that's much more than a one-liner change :)
How to test the change?:
Change includes code coverage.