Async-context formalization and diagnostics support
mrkmarron opened this issue · 5 comments
Updating text here to better reflect reality - mike-kaufman
Current Status:
- high-level description of async context is checked into Diag repo in form of slides
- Update slides to account for the following
- explicit APIs for how to do property lookups. Support "lazy init promises"
var p; app.get('/', (req, res) = { if (!p) { p = someAsyncFuncThatReturnsAPromise(); } p.then(() => {…}); });
- Promise.all(), Promise.race()
- Async/Await examples
- generator examples
- async generator examples
- async recurision and path compression support (e.g.,
f = () = > { setTimeout(f, 1000); }
) - specific API changes (I.e., what APIs/properties get exposed through JS to users)
- explicit APIs for how to do property lookups. Support "lazy init promises"
- Get plan on how to take to TC-39
- Identify how ready-context can be implemented based on current promise hooks APIs
- Understand perf impact
causal context: relates f^i causes g^j if during the ex- ecution of f^i
the function g^j is enabled for execution via an E-Then rule application
on an already resolved priority promise or via an E-Resolve rule application
on a previously un-resolved priority promise.[...]
For programs that do not use JavaScript promises and rely on raw callbacks the linking context and causal context will be the same at all program points.
I assume the above is meant as "without additional signals" / "in the scope of the formal language described in the paper"? E.g. the following doesn't use "real" Promises but still de-facto has different linking/causal context if I understand it correctly:
var connection;
var queued = [];
function runWithConnection(cb) { // userland E-Then
if (connection) { cb(connection); }
else { queued.push(cb); }
}
function setConnection(c) { // userland E-Resolve
connection = c;
queued.forEach(f => f(c));
}
setConnection(net.connect(/* ... */)); // ~ calling E-Resolve
runWithConnection(postConnect); // ~ calling E-Then
Nevermind, looks like the paper includes that in the context tracking instead of trying to include it in the more general abstractions.
Investigate how the general formalisms in the paper handle various corner cases (such as Promise.all).
Would it make sense to collect these in a runnable form? E.g. starting an acceptance suite that just defines the cases but not even necessarily the expected values for causal and/or linking context?
FYI the (very rough) draft of this formalization is here: https://github.com/mike-kaufman/async-context-definition. It's still rough, look for more of it to fill out over the next month.
should this remain open? [ I am trying to chase dormant issues to closure ]
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.