TC39 Async Context
2023-03-08
plaintext logs
prev next
source on github
18:20
<Justin Ridgewell>
We have spec text! https://tc39.es/proposal-async-context/
18:21
<Justin Ridgewell>

I think the only surprising change is the addition of [[Construct]] on wrapped callbacks:

const Foo = AsyncContext.wrap(class Foo {});

// The wrapper will invoke construct on the wrapped function
new Foo();
18:22
<Justin Ridgewell>
This comes from the behavior of Function.p.bind
20:25
<littledan>
yeah I am OK with including or omitting the [[Construct]] behavior
20:42
<littledan>
the spec would probably be clearer if we could use whatwg infra algorithms
20:42
<littledan>
(for the mapping)
20:43
<littledan>
we should probably think about exposing reusable algorithms (for web specs) for get and run, but this is an editorial thing
20:44
<littledan>
it might be nicer editorially if we avoided SameValueZero; SameValue or simply = is enough. (But the nicest would be to say that it's a mapping...)
20:44
<littledan>
anyway I don't see any bugs in the spec; looks good for Stage 2 to me
20:48
<Andreu Botella>
IIRC the setTimeout infrastructure in HTML jumps off-thread to sleep, and then queues a task on the event loop
20:48
<Andreu Botella>
a setTimeout that wraps the callback would have to "send" a snapshot off-thread
20:48
<Andreu Botella>
is that fine, as long as the values are not read?
20:49
<littledan>
I'm not sure if it should be phrased like that
20:49
<littledan>
I hope that you can work with ms2ger and Yoav on a proposed wording here
20:50
<littledan>
I think queued tasks would often carry asynccontext snapshots with them, but that snapshot shouldn't ever logically leave the main thread
20:51
<littledan>
in any case, you'll want to have clean abstract algorithms for creating an AsyncContext, and get and run, so that the embedding spec doesn't need to call the actual JS functions