|
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.
|