-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Service Arch 2022-05-30
-
135
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Work on SERVER-66385 revealed that ThreadContext doesn't and likely cannot live up to the promise in its documentation of being in a 1-to-1 (bijective) relationship with threads. It can only come into existence when a thread calls ThreadContext::get after MONGO_INITIALIZERs and before static duration object destruction. These contraints are a source of several recent bugs.
As a Decorable, it can only be created after MONGO_INITIALIZERs, which makes it harder to reason about, and it cannot be used during program shutdown (SERVER-58194 is a bug caused by this). As a thread_local, it must be destroyed before static objects so it is unavailable at shutdown time, even for the main thread. After SERVER-66385, we don't actually need a ThreadContext at all.
The only remaining use of ThreadContext is a recent test (according to comments in the test it is nondeterministic anyway (https://github.com/mongodb/mongo/commit/263c0631c8001a8cdb42aff720b8a49a621754dd#diff-db39491b47a2be852cb29c36e80fd1932a990c129bd17586578bfed398626b38) , and what it's doing can be better done with `FailPoint` or other test injection techniques, as there's a specific thread spawn call that it's looking for.
- depends on
-
SERVER-66385 Remove ThreadName's dependence on ThreadContext (& vice versa apparently)
-
- Closed
-
- related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-
- split to
-
-
- Closed
-