Async-context formalization and diagnostics support

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

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.

Navigation Menu

Repository navigation

Async-context formalization and diagnostics support #107

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Async-context formalization and diagnostics support #107

Description

Activity

hybrist commented on Nov 29, 2017

hybrist commented on Nov 29, 2017

mike-kaufman commented on Dec 17, 2017

gireeshpunathil commented on Oct 25, 2019

github-actions commented on Jul 19, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions