TC39 Async Context
2024-12-02
plaintext logs
prev next
source on github
02:21
<Taral>
I see references to enterWith but basically nothing in github about it?
02:22
<Andreu Botella>
I see references to enterWith but basically nothing in github about it?
Hi. This refers to the enterWith method in Node.js's AsyncLocalStorage
02:22
<Taral>
Ahh
02:22
<Andreu Botella>
https://nodejs.org/docs/latest/api/async_context.html#asynclocalstorageenterwithstore
02:23
<Taral>
Yeah, that's weird. It's basically like putting var.run around the entire continuation.
02:28
<Taral>
So "AsyncContext v2" is also a Node reference?
02:29
<Andreu Botella>
So "AsyncContext v2" is also a Node reference?
I don't know what it's a reference to, where did you see that?
02:33
<Taral>
I prototyped a quick proof-of-concept that it's possible to leverage most of an existing implementation and add a disposable enterWith by just replacing AsyncContext.Variable with a new implementation that indirects through a single "real" variable: https://gist.github.com/shicks/0cd7e9b06535793c137934cc52ed12ce
This gist references v2.
02:34
<Andreu Botella>
oh, right, this refers to https://github.com/tc39/proposal-async-context/pull/101, which are ideas for an extension to AsyncContext
02:34
<Taral>
 * ~~Maybe I imagined it? Not finding it any more.~~
02:34
<Taral>
ah thx
02:35
<Taral>
Starts to look a bit like Jetpack Compose's snapshots.
02:36
<Andreu Botella>
I'm not familiar with those
02:41
<Andreu Botella>
(completely disconnected topic:) I'm wondering if we should also have a resetFallbackContext API, to isolate inner scopes
02:41
<Andreu Botella>
the SES folks would probably appreciate that
02:41
<Taral>
https://blog.zachklipp.com/introduction-to-the-compose-snapshot-system/ is probably the best explanation
02:43
<Taral>
It's kind of built on Kotlin's CoroutineContext, which is basically the same as AsyncContext.
02:44
<Taral>
(albeit with a somewhat different interface)
17:20
<Jan Olaf Martin>
After a chat about async context with Steve Hicks, I was wondering if other (non-fetch/non-xhr) async network operations should also preserve context? E.g. image and/or script loading triggers and their onload handlers.
18:22
<Steve Hicks>
(completely disconnected topic:) I'm wondering if we should also have a resetFallbackContext API, to isolate inner scopes
What would resetFallbackContext do? Would it escape out of whatever fallback context it was previously in? That seems problematic, if fallback contexts were supposed to be able to isolate entire (transitive) chunks of code? Though, I'm very skeptical of the security implications of AsyncContext at all - specifically, I don't think we can confidently guarantee that isolated inner code can never access outer/root/empty contexts - it seems too easy to smuggle a foreign context. (For instance, we've talked about how addEventListener interacts with runWithFallbackContext, but would onclick setters also respect the same fallback? If they're not all currently implemented as setter properties, then this might be extremely infeasible to change)
18:23
<Andreu Botella>
I was thinking that it would reset to the empty context
18:24
<Steve Hicks>
Yeah, that's weird. It's basically like putting var.run around the entire continuation.
As we talk about more and more callback-accepting APIs (runWithFallbackContext, resetFallbackContext, etc, on top of Variable#run and Snapshot#run), will all of these be rendered obsolete if we end up exposing a set/enterWith API?
18:25
<Steve Hicks>
I was thinking that it would reset to the empty context
This maybe suggests it's worth making it explicit that empty context should never be considered privileged?
18:28
<nicolo-ribaudo>
As we talk about more and more callback-accepting APIs (runWithFallbackContext, resetFallbackContext, etc, on top of Variable#run and Snapshot#run), will all of these be rendered obsolete if we end up exposing a set/enterWith API?
In Node.js I still see significant usage of .run, even if there is .enterWith (!!! this is not backed up by data, just by me looking at .enterWith usage patterns a month ago)
18:29
<Steve Hicks>

If you have access to the empty context, you could write (in userland)

function resetFallbackContext(fn) {
  const snapshot = new AsyncContext.Snapshot();
  return EMPTY_SNAPSHOT.run(() => runWithFallbackContext(() => snapshot.run(fn)));
}
18:29
<Steve Hicks>
(though the 3-8 extra frames on the stack are unfortunate)
18:30
<nicolo-ribaudo>
I'm not sure I understand the use case for resetFallbackContext
18:31
<Andreu Botella>
the use case I see is establishing a security boundary
18:35
<nicolo-ribaudo>
But it does the opposite: it lets you escape the boundary that your caller set up for you
18:35
<nicolo-ribaudo>
(note: this is not about security, since there are many ways to get to the root context)