[SERVER-66126] Clear Future/ExecutorFuture continuations as they run Created: 02/May/22  Updated: 20/Dec/23

Status: Open
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matt Diener (Inactive) Assignee: Backlog - Service Architecture
Resolution: Unresolved Votes: 0
Labels: techdebt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-66127 Introduce the LegacyDestructorOrderin... Backlog
depends on SERVER-66128 Implement guaranteed continuation des... Backlog
depends on SERVER-66129 Provide directions to clean up Legacy... Backlog
is depended on by SERVER-66243 Unwind continuation chains with a loop Backlog
Duplicate
is duplicated by SERVER-54119 Destroy SharedStateBase as we unfold ... Closed
Related
related to SERVER-52942 Evaluate whether we could change the ... Closed
related to SERVER-53538 Clarify semantics of when destructor ... Closed
Assigned Teams:
Service Arch
Sprint: Service Arch 2022-05-16, Service Arch 2022-05-30, Service Arch 2022-06-13, Service Arch 2022-06-27, Service Arch 2022-07-11
Participants:
Linked BF Score: 2

 Description   

It has been reported to the Service Architecture team that destructor ordering of continuation chains is not well-understood among server developers. This has come up in Slack and issues have been logged:

SERVER-53538 - Clarify semantics of when destructor runs for ExecutorFuture chains
SERVER-54119 - Destroy SharedStateBase as we unfold continuations
SERVER-52942 - Evaluate whether we could change the destruction order of the closure in the ExecutorFuture class

After some investigation, we’ve determined that the semantics around when continuation lambdas get destroyed are difficult to predict. This is mainly because the current implementation does not explicitly define a point at which the user-provided function is no longer held. Our current understanding is represented by the matrix below. It represents the known combinations of conditions that can impact the way that continuation functions run, and hence the multiple code paths that can lead to different destructor orderings:

This issue encompasses the entirety of the work involved in moving to guaranteed destructor semantics.

  1. Implement both behaviors using a template argument in the implementation details. (SERVER-66128)
  2. Write up a doc explaining destructor semantics and provide direction to Server contributors for upcoming work. (SERVER-66129)
  3. Uglify all code to employ a LegacyDestructorOrdering tag on all continuations, and delegate some Jira tickets. (SERVER-66127)
  4. Wait for teams to address issues. (bugs pending)
  5. Remove tags and remove the legacy delete ordering semantics. (this SERVER-66126)

This task can be closed with the completion of step 5.


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