Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-66456

remove ThreadContext

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 6.1.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Fully Compatible
    • ALL
    • Service Arch 2022-05-30
    • 135

      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.

            billy.donahue@mongodb.com Billy Donahue
            billy.donahue@mongodb.com Billy Donahue
            0 Vote for this issue
            3 Start watching this issue