[SERVER-66243] Unwind continuation chains with a loop Created: 05/May/22  Updated: 06/Dec/22

Status: Backlog
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: futures
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-66126 Clear Future/ExecutorFuture continuat... Open
Assigned Teams:
Service Arch
Participants:

 Description   

Currently continuation chains are being resolved with a call stack based approach. This has a couple consequences:

  • Challenging callback destructor ordering semantics which need to be individually addressed in SERVER-66126
  • Large stacks leading to stack overflows

Currently, the benefit that we get from the stack based resolution is some extra context in dumps (only with non-executor continuations on non-ready futures). Before committing to this task, it's worth considering whether that benefit is worth preserving, and it's worth looking into improvements that can be made to debugability in all cases.



 Comments   
Comment by Mathias Stearn [ 30/May/22 ]

As part of this we can make ExecutorFuture much cheaper by just continuing the loop if we are running directly from the executor callback function on the correct executor rather than scheduling a new task for each link in the Future chain. Right now we can't do that because we don't know what context we are being called from so we conservatively call schedule() every time.

Comment by Matt Diener (Inactive) [ 05/May/22 ]

I don't think there's a way to implement this before we are fully moved over to the new destructor ordering semantics. It'd be very hard to implement this any other way.

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