[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:
Depends
is depended on by SERVER-66455 Undo ~OpMsgFuzzerFixture fix Closed
is depended on by SERVER-66456 remove ThreadContext Closed
Issue split
split from SERVER-63852 getThreadName() should not crash Closed
Problem/Incident
Related
related to SERVER-66464 use LLVMFuzzerRunDriver for OpMsgFuzz... Open
related to SERVER-58194 Fix undefined behavior in the destruc... Closed
related to SERVER-63852 getThreadName() should not crash Closed
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.
For maximum generality, it should not have any idea what mongodb is.
The idea that there's a "pre-init" for ThreadName, or that it depends on a MONGO_INITIALIZER for ThreadContext to get started is a bad fit that
causes bugs: SERVER-58194, SERVER-63852.

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: SERVER-66385 separate ThreadName from ThreadContext
Branch: master
https://github.com/mongodb/mongo/commit/44629a3516e8d94f5dd5509e896e4c34801f8527

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

> * A ThreadContext is a simple decorable that has an explicit one-to-one relationship with threads.

No it doesn't. I'll fix the inaccurate docs too.

Generated at Thu Feb 08 06:05:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.