[SERVER-66385] Remove ThreadName's dependence on ThreadContext (& vice versa apparently) Created: 11/May/22 Updated: 29/Oct/23 Resolved: 13/May/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Billy Donahue | Assignee: | Billy Donahue |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Sprint: | Service Arch 2022-05-16, Service Arch 2022-05-30 | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Linked BF Score: | 135 | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
ThreadName is a low-level diagnostic, not a db business object. After working on ThreadName's API I don't see a reason for it to be connected to ThreadContext. |
| Comments |
| Comment by Githook User [ 13/May/22 ] |
|
Author: {'name': 'Billy Donahue', 'email': 'billy.donahue@mongodb.com', 'username': 'BillyDonahue'}Message: |
| Comment by Billy Donahue [ 13/May/22 ] |
|
Figured it out. ThreadContext doesn't actually exist on a thread until code executing on that thread accesses it with ThreadContext::get(). The code in TransportLayerASIOWithServiceContextTest, and perhaps other code, was depending on the construction of decorations of ThreadContext to detect the starting and ending of threads. This only got us as far as it did because LOGV2 statements would access getThreadName which implies an access to ThreadContext::get, which caused ThreadContext to be created for new threads pretty soon after they were created, but only if they did any logging. So if ThreadName has nothing to do with ThreadContext anymore (as proposed in this ticket), then nothing else creates ThreadContext for new threads. I think the intent of ThreadContext was that it should exist for all threads for their whole lifespan, not just after they emit their first log statement, so one solution is to add a call to ThreadContext::get at the beginning of the stdx::thread callback wrapper. We don't need to use the returned value and can just discard it, but we need the construction side effect. https://github.com/10gen/mongo/blob/master/src/mongo/util/thread_context.h#L42
No it doesn't. I'll fix the inaccurate docs too. |