Async-context formalization and diagnostics support

[mrkmarron]

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)
• 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

[jkrems]

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.

[jkrems]

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?

[mike-kaufman]

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.