[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: |
|
||||||||
| Assigned Teams: |
Service Arch
|
||||||||
| Participants: | |||||||||
| Description |
|
Currently continuation chains are being resolved with a call stack based approach. This has a couple consequences:
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. |