-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:
-
Storage Execution
-
Execution Team 2022-11-14, Execution Team 2022-12-12, Execution Team 2022-11-28
Uses of UninterruptibleLockGuard indicate places in the code that do not comply with MongoDB's requirement that all operations be interruptible at places where they block to wait for resources. Every one of them is a potential future deadlock, and adds complexity to other parts of the codebase. We should reimplement codepaths that depend on UninterruptibleLockGuard so as to be interruptible.
- depends on
-
SERVER-71610 [StorEx] Remove or document instances of UninterruptibleLockGuard
- Closed
-
SERVER-68874 Consider making waitAfterPinningCursorBeforeGetMoreBatch only hang instead of also fiddling with locks (while-loop taking and releasing locks)
- Closed
-
SERVER-71444 [Sharding] Remove or document instances of UninterruptibleLockGuard
- Open
-
SERVER-68867 Use linter to prevent new instances of UninteruptibleLockGuard
- Closed
-
SERVER-71441 [Query] Remove or document instances of UninterruptibleLockGuard
- Closed
-
SERVER-71443 [Replication] Remove or document instances of UninterruptibleLockGuard
- Closed
- related to
-
SERVER-69506 An InterruptibleLockGuard should be placed in the PlanExecutorSBE class as a private member if the use cases are expanded beyond the find/agg/getMore commands while the UninterruptibleLockGuard still exists
- Backlog
-
SERVER-68867 Use linter to prevent new instances of UninteruptibleLockGuard
- Closed