TC39 Async Context
2024-07-18
plaintext logs
prev next
source on github
12:26
<Andreu Botella>
so for events in the web integration, the current idea (since we discussed it with various web platform folks in the Web Engines Hackfest) is to add a property to the event object containing the AsyncContext.Snapshot for the originating/causal event (possibly null)
12:27
<Andreu Botella>
does anyone want to pitch in with ideas for the name of that property? originatingContext? causalContext? causalContextSnapshot?
12:27
<Andreu Botella>
I'm not sure any of those are great, does anyone have ideas?
13:04
<littledan>
I vote that we try to consistently use the term “snapshot” when referring to context maps
13:05
<littledan>
But there are many possible ways to call this while including that word
16:31
<Steve Hicks>
Relevant words: origin(al|ating)?, trigger(ing)?, causal, dispatch(-time)?, unrestored, outer, source, init(ial|iating), starting, previous, flow(-through)?
16:33
<Steve Hicks>
I'm partial to originSnapshot, dispatchSnapshot, or initialSnapshot, I think.
16:37
<nicolo-ribaudo>
Origin already has a meaning on the web, I would prefer anything else
16:48
<Steve Hicks>
Ok, then (1) originalSnapshot, (2) originatingSnapshot, (3) dispatchSnapshot, or (4) initialSnapshot.
17:51
<snek>
asyncContextSnapshot
17:58
<Stephen Belanger>
dispatchContext makes sense to me in this specific context as it indicates it's specifically when the event dispatch call happened.
18:06
<snek>
i would be sad if this didn't include at least "async" in it
18:07
<snek>
dispatchAsyncContextSnapshotNotAnOriginDoNotConfuseWithAnOrigin
18:27
<Steve Hicks>
Tomorrow is the deadline for adding agenda items for advancement at the August plenary - are we still on target to present something?
19:10
<nicolo-ribaudo>
I've seen from the outside how much work has gone in the web integration, I think a status update on that would be very valuable
19:13
<Justin Ridgewell>
To everyone not following the TC39 General room, there’s been some discussion on AsyncContext:

  1. https://matrixlogs.bakkot.com/TC39_General/2024-07-16

  2. https://matrixlogs.bakkot.com/TC39_General/2024-07-17

  3. https://matrixlogs.bakkot.com/TC39_General/2024-07-18

19:23
<Justin Ridgewell>
In particular, @bakkot has some dislike of through-await continuation semantics in:

  1. https://matrixlogs.bakkot.com/TC39_General/2024-07-17#L56

  2. https://matrixlogs.bakkot.com/TC39_General/2024-07-17#L67

  3. https://matrixlogs.bakkot.com/TC39_General/2024-07-17#L75


Which had to be resolved in https://matrixlogs.bakkot.com/TC39_General/2024-07-17#L80-L81
19:49
<bakkot>

specifically:

async function f() {
  await scheduler.yield();
  await someLibrary.doWork();
  await scheduler.yield(); // this should not be affected by the `doWork` call
}

as long as that's maintained, I'm not worried

19:50
<bakkot>
obviously if doWork closes over an async context variable which has a mutable object or whatever then it can affect it, just like if it closed over a regular variable; that's fine
19:51
<bakkot>
(assuming there aren't any such which exist by default)
19:51
<Justin Ridgewell>
For the last few weeks, we’ve been discussing Contunation variables which behave differnetly than AsyncContext.Variable does: https://github.com/tc39/proposal-async-context/pull/94
19:54
<Justin Ridgewell>
const aVar = new AsyncContext.Variable();
const cVar = new ContinuationVariable();

function foo() {
  return aVar.run(2, () => {
    return cVar.run(2, () => {
      // aVar.get() === 2
      // cVar.get() === 2
      return Promise.resolve();
    });
  });
}

aVar.run(1, () => {
  cVar.run(1, async () => {
      // aVar.get() === 1
      // cVar.get() === 1

      await foo();

      // aVar.get() === 1
      // cVar.get() === 2
  });
});
19:56
<Justin Ridgewell>
Continuation variables keep the data that’s set when the promise resolves (like a callback passing data), while AsyncContext.Variables keep the data that’s set immediately before awaiting a promise (like a parameter).
19:59
<bakkot>
surely it should be called set or something in that case, yes? there's no reason to use the run(val, cb) pattern if the value is persisted after the callback finishes
20:00
<Chengzhong Wu>
It's not "persist" as you'd expect after the callback finishes
20:01
<Justin Ridgewell>
Yah, there’s a difference between sync mutation (which SES folks very much disliked) and the Promise holding context data from its resolution (which SES folks maybe won’t object to)
20:01
<Chengzhong Wu>
const cv = new ContinuationVariable();

const p1 = cv.run(1, () => asyncFunction());
const p2 = cv.run(2, () => asyncFunction());
cv.get(); // undefined
await p1;
cv.get(); // 1
await p2;
cv.get(); // 2

or...

const cv = new ContinuationVariable();

cv.set(1);
const p1 = asyncFunction();
cv.set(2);
const p2 = asyncFunction();
cv.get(); // 2
await p1;
cv.get(); // 1
await p2;
cv.get(); // 2
20:02
<Justin Ridgewell>
Continuation could be implmemented via mutation, but doesn’t need to be.
21:05
<Steve Hicks>
(assuming there aren't any such which exist by default)
So you're saying that if there were a global AsyncContext.Variable<AbortSignal> that might be a problem? IIUC this is something littledan and I are interested in pursuing. On the other hand, maybe it's fine because the signal itself is read-only, and you need access to the controller to actually mutate it...?
21:06
<bakkot>
I'd have to think more about that but it's mostly the mutable cases I'm concerned about yes
21:07
<bakkot>
but signals are not frozen objects
21:07
<Steve Hicks>
no, but you need additional access to effect a mutation on them
21:07
<bakkot>
no you don't
21:08
<Steve Hicks>
oh, you mean a side channel like adding a prop
21:08
<bakkot>
x = (new AbortController).signal; x.y = 0; x.y // 0
22:15
<littledan>
one option is just to let you add reactions to the signal, and not actually expose it
22:17
<littledan>
like imagine https://gist.github.com/littledan/47b4fe9cf9196abdcd53abee940e92df?permalink_comment_id=5094185#implicit-propagation-of-abortsignal but there's no ambient getter and only the whenAborted call