TC39 Async Context
2023-02-01
plaintext logs
prev next
source on github
14:01
<littledan>
Good luck, Justin Ridgewell and Chengzhong Wu !
14:48
<Ben Newman (Apollo, @benjamn on GH)>
good luck! calm nerves!
15:59
<Ben Newman (Apollo, @benjamn on GH)>
congrats on stage 1!!
16:01
<Justin Ridgewell>
Thanks!
16:02
<Chengzhong Wu>
Justin Ridgewell awesome work!
16:04
<James M Snell>
nice
16:04
<James M Snell>
great job all
16:08
<James M Snell>
I likely missed the link somewhere so my apologies, but are the slides used for the discussion available?
16:08
<Chengzhong Wu>
yes, it's public: https://docs.google.com/presentation/d/1yw4d0ca6v2Z2Vmrnac9E9XJFlC872LDQ4GFR17QdRzk/edit#slide=id.p
16:48
<Justin Ridgewell>
PSA: V8 advises against shipping usages of ContinuationPreserveEmbedderData as it does not handle multiplexing multiple usages, and is likely to change in the future as we consider AsyncContext.
16:49
<Justin Ridgewell>
Meaning values that are stored there are overwritten by later calls
16:49
<Justin Ridgewell>
If node were to add AsyncLocalStorage data there, then nothing else in node could set data there
16:50
<Justin Ridgewell>
But I don't think this is a problem, just use the ALS APIs to set any other data
16:52
<Justin Ridgewell>
@room I'm taking this room public!
16:52
<Ben Newman (Apollo, @benjamn on GH)>
I very much agree that any way of exposing the continuation capability should not monopolize it for other usage
16:52
<Ben Newman (Apollo, @benjamn on GH)>
every AsyncContext should feel totally orthogonal/independent of any others
16:52
<littledan>
Let's make a nicer title for this room
16:53
<littledan>
Justin Ridgewell: You can do this in settings (or give me admin capabilities and I'd do it)
16:53
<Justin Ridgewell>
Are you not already?
16:53
<Justin Ridgewell>
Can we move it into the TC39 space, too?
16:54
<James M Snell>

V8 advises against shipping usages of ContinuationPreserveEmbedderData as it does not handle multiplexing multiple usages

Making sure I understand the "multiplexing multiple usages".. you mean like having multiple AsyncContext/AsyncLocalStorage instances?

16:54
<Justin Ridgewell>
No
16:54
<Justin Ridgewell>
Chrome is currently setting Task Attribution data their directly, meaning we can't directly set AsyncContext data there (because it would overwrite the TA data)
16:55
<Justin Ridgewell>
If we reserve the continuation data for AsyncContext, then Task Attribution would need to use our APIs to set data there
16:55
<littledan>

V8 advises against shipping usages of ContinuationPreserveEmbedderData as it does not handle multiplexing multiple usages

Making sure I understand the "multiplexing multiple usages".. you mean like having multiple AsyncContext/AsyncLocalStorage instances?

Yeah, I would say, logically "yes", that that conflict that Justin is taling about is a form of this at a high level
16:55
<Justin Ridgewell>
They can't directly set/get anymore
16:55
<Ben Newman (Apollo, @benjamn on GH)>
could Chrome use an AsyncContext for task attribution, theoretically?
16:56
<littledan>
The other thing is that Shu was saying the API may change over time
16:56
<Justin Ridgewell>
Yes
16:56
<littledan>
could Chrome use an AsyncContext for task attribution, theoretically?
This is precisely our hope
16:56
<littledan>
BTW I wrote that conclusion in the notes, please feel free to edit it
16:56
<James M Snell>
ah right. so it's really currently an embedder specific limitation. In our case (workerd), we're not using it for anything else, but a chrome implementation of AsyncContext couldn't use it because it's already being used for other things
16:57
<Justin Ridgewell>
Correct
16:58
<littledan>
ah right. so it's really currently an embedder specific limitation. In our case (workerd), we're not using it for anything else, but a chrome implementation of AsyncContext couldn't use it because it's already being used for other things
exactly. They also might remove the API.
16:58
<James M Snell>
hypothetically, chrome could adopt a model similar to what we're doing in workerd and store a context frame (map of keys to stored values) in the slot instead of the value directly
16:58
<littledan>
hypothetically, chrome could adopt a model similar to what we're doing in workerd and store a context frame (map of keys to stored values) in the slot instead of the value directly
Right, this is what we hope to move into V8
16:58
<Ben Newman (Apollo, @benjamn on GH)>
is there value in discussing an even lower-level safe/restricted API around v8::Context::{Get,Set}CPED, or is AsyncContext the lowest level we want?
16:59
<James M Snell>
this is how we deal with multiplexing the field. each ALS/AC instance represents a key in that frame
16:59
<James M Snell>
perfect, ok
16:59
<littledan>
is there value in discussing an even lower-level safe/restricted API around v8::Context::{Get,Set}CPED, or is AsyncContext the lowest level we want?
I think we should have a C++ API which maps to/from AsyncContext. I don't think it should leave out the try/finally nesting logic, though.
17:00
<Ben Newman (Apollo, @benjamn on GH)>
so I built something like this for my prototype
17:01
<Ben Newman (Apollo, @benjamn on GH)>
a C++-backed function you can call (with an optional default value), to get another function that can either return the current value if called without args (note: just your value, not the whole map) or run a function with a new value set in the map, when called with that new value and a callback
17:02
<Ben Newman (Apollo, @benjamn on GH)>
but I have to admit that feels awfully close to what AsyncContext is, just more functional and less OO
17:03
<Ben Newman (Apollo, @benjamn on GH)>
the key is that you can get as many independent context values from that API as you want, so nobody steps on anyone else's toes
17:04
<bakkot>
if you move this room to the TC39 space make history public then it should get picked up by https://matrixlogs.bakkot.com/ automatically
17:26
<bakkot>
https://github.com/legendecas/proposal-async-context/issues/22
17:28
<Andreu Botella>
is this moved already? I can't see the room in the https://matrixlogs.bakkot.com/ channel list
17:29
<Justin Ridgewell>
Not yet
17:29
<Justin Ridgewell>
Waiting on a TC39 admin do move it to this space
17:31
<ljharb>
it's moved now - sorry for the delay; ping me if you have any other matrix admin issues
17:31
<rbuckton>
I mentioned this in the delegates chat, but I'll leave it here as well. Assuming AsyncContext automatically flows through .then, we should ensure that AsyncContext will automatically flow through calls to AsyncDisposableStack.prototype.disposeAsync to registered [Symbol.asyncDispose]() methods and adopt/defer callbacks.
17:31
<bakkot>
rbuckton: Is your expectation that anyone doing any kind of control flow abstraction should be updating their code to flow async contexts?
17:31
<bakkot>
Or just the ones which are built in, and then users have to figure out which is which?
17:32
<bakkot>
Like, I've definitely built control flow abstractions on top of addEventListener in the past
17:33
<bakkot>
and would have been absolutely shocked to learn those weren't transparent because of this context thing
17:34
<bakkot>
It is not that unusual for me to make a custom thenable which schedules its callback via some mechanism other than Promise.prototype.then
17:34
<littledan>
What does “transparent” mean to you?
17:34
<rbuckton>
rbuckton: Is your expectation that anyone doing any kind of control flow abstraction should be updating their code to flow async contexts?
What kind of abstraction? I have many async control flow and coordination classes in @esfx/*, and yes I would choose to support them in my library in places where they would not otherwise automatically flow, but on a case by case basis.
17:34
<bakkot>
littledan: it's not transparent if I as the library author who is not using async contexts have to be aware of async contexts because my users might use them
17:35
<bakkot>
it is transparent if I do not have to think about async contexts when I am not using async contexts
17:35
<bakkot>
If we're going to say that library authors all have to think about async contexts anyway, we can just say they should pass around contexts like any other state
17:35
<rbuckton>
I'll follow up more later, I need to eat and get ready for my presentation.
17:35
<bakkot>
i.e., explicitly, as values, on the stack
17:36
<bakkot>
async contexts are only a win if people who are not using them don't have to think about them
17:36
<littledan>
So, yes, it is implicit in this proposal that library authors, when they take callbacks, should probably think about AsyncContext if they want to meet their users’ expectations.
17:36
<littledan>
I don’t know what the bad part is, though
17:36
<bakkot>
Hm. That's literally the opposite of what I heard in the presentation.
17:37
<bakkot>
The thing I heard was, we want to manage contexts for our code which is passing callbacks to other people's code without the other people's code having to cooperate with that.
17:37
<littledan>
The presentation was about library users
17:37
<rbuckton>
If we're going to say that library authors all have to think about async contexts anyway, we can just say they should pass around contexts like any other state
A library adding support is significantly better than every individual consumer of that library needing to add support themselves.
17:38
<bakkot>
Disagree; AsyncContexts are niche feature, libraries are not.
17:38
<littledan>
I used to think AsyncContext was niche; I no longer think so
17:39
<littledan>
It is already central in servers, and lots of frontend frameworks would use it if they had it
17:39
<littledan>
Plus browser features would use it if they had it, and libraries using wrap appropriately would make the browser work better
17:39
<bakkot>
The thing I heard was, we want to manage contexts for our code which is passing callbacks to other people's code without the other people's code having to cooperate with that.
Like, was that not an accurate understanding of the presentation?
17:39
<bakkot>
If this was not an accurate understanding of the presentation I am now extremely confused what the feature is even for.
17:40
<littledan>
Yeah users of the platform have this handled automatically
17:40
<Justin Ridgewell>
Like, was that not an accurate understanding of the presentation?
I'm a platform, not a library
17:40
<littledan>
I'm a platform, not a library
Same thing for this discussion
17:40
<bakkot>
If the feature is only for "platforms" I am much less interested in it.
17:40
<Justin Ridgewell>
It's definitely not the same
17:40
<littledan>
It is not only for platforms
17:41
<Justin Ridgewell>
User code can't execute unless it is within my context, and it cannot be scheduled without my direct involvement
17:41
<Justin Ridgewell>
That's not true for libraries
17:41
<rbuckton>
Disagree; AsyncContexts are niche feature, libraries are not.
There are significantly more end user applications that consume libraries than there are libraries. By moving the burden to the end user application developer, you are significantly increasing cost (both in time and in $, I imagine).
17:41
<littledan>
That's not true for libraries
Oh right yes platforms can reach this air tightness
17:41
<Andreu Botella>
I don't think it makes much sense to treat a click event listener the same as an await
17:42
<bakkot>
There are significantly more end user applications that consume libraries than there are libraries. By moving the burden to the end user application developer, you are significantly increasing cost (both in time and in $, I imagine).
Only if end user applications are frequently using async contexts. I am a lot more OK with asking people who are using a feature to pay the cost of the feature.
17:42
<bakkot>
Especially when the "cost" is "you are passing a callback out of your library; make sure to wrap it so it gets the context preserved"
17:42
<bakkot>
like, that's not a huge ask.
17:43
<bakkot>
I don't think it makes much sense to treat a click event listener the same as an await
What's the relevant difference here?
17:44
<bakkot>
User code can't execute unless it is within my context, and it cannot be scheduled without my direct involvement
If the feature is only motivated by platforms-in-this-sense, it is not IMO sufficiently motivated, so I think it would be helpful to figure out whether and how it's useful for people not in your quite unique situation
17:45
<bakkot>
What's the relevant difference here?
or I guess to be more precise: I agree about await, but what's the relevant difference between a click listener and Promise.prototype.then?
17:45
<littledan>
like, that's not a huge ask.
I think this is the kind of claim which we can analyze by looking at the many many analogous systems with experience here
17:46
<littledan>
I really wasn’t convinced of this feature until I saw the need and implementations over and over again
17:46
<Andreu Botella>
What's the relevant difference here?
you can set element.onclick inside a callback called from a framework without treating the click handler as part of the framework's context
17:46
<littledan>
I agree with bakkot that if this were niche it would be questionable complexity
17:46
<bakkot>
ljharb: can you make history for this room public?
17:46
<bakkot>
(I don't know how to do it but I don't think it currently is)
17:46
<Andreu Botella>
I'll try to think of a more concrete example for the click event though
17:47
<littledan>
I made history public
17:47
<ljharb>
bakkot: i can't see history prior to the room being public - it says "You can't see earlier messages. Encrypted messages before this point are unavailable."
17:47
<bakkot>
you can set element.onclick inside a callback called from a framework without treating the click handler as part of the framework's context
you can Promise.prototype.then inside a callback called from a framework without treating the thing passed to the handler as part of the framework's context also, though
17:47
<bakkot>
(I agree about await, but not P.p.then)
17:48
<bakkot>
bakkot: i can't see history prior to the room being public - it says "You can't see earlier messages. Encrypted messages before this point are unavailable."
yeah, the thing littledan did should be sufficient. (you can't make history retroactively public, which is IMO a good thing)
17:48
<Justin Ridgewell>
I think I really screwed up making this room originally
17:48
<Justin Ridgewell>
😬
17:50
<Justin Ridgewell>
Do we need to do anything else to get this picked up?
17:55
<bakkot>
that should have been sufficient but I think there might be a bug on my end
18:01
<bakkot>
hm. no there's just no history yet.
18:01
<bakkot>
somehow
18:01
<bakkot>
https://view.matrix.org/room/%21siOjSOrhCVYVzIoThy:matrix.org/
18:02
<bakkot>
testing, testing, trying to get this to show up in the history...
18:07
<bakkot>
if logs don't show up in https://view.matrix.org/room/%21siOjSOrhCVYVzIoThy:matrix.org/ they also won't show up on my logbot. I have no idea why logs don't show up at that link though.
18:07
<ljharb>
it's an "encrypted room" so that might be why
18:08
<ljharb>
which can't be disabled
18:08
<ljharb>
so if that's the problem, we might need to create a new room and scrap this one
18:08
<bakkot>
what does it mean to have globally visible history if it's encrypted...
18:08
<Andreu Botella>
oh, so the public API can't pick it up, only a bot that joined the room can
18:08
<bakkot>
I can make my bot join this room I guess
18:17
<littledan>
if that doesn't work, it'd be fine to switch rooms
18:17
<bakkot>
bot probably can't pick up history from before it joined
18:18
<bakkot>
but we'll see in a few minutes if it can pick this up
18:20
<Justin Ridgewell>
If it helps, we can export the early logs
18:20
<littledan>
I think future logs are the main thing
18:20
<Justin Ridgewell>
Yah
18:23
<bakkot>
it cannot, apparently, though I don't know why not
18:23
<bakkot>
probably need to make a new room
18:23
<Andreu Botella>
but we'll see in a few minutes if it can pick this up
https://github.com/bakkot/matrix-logs/commit/7798d80d3c4c45af248733855824d15285cd879f <- there's a last seen event, but no actual logs
18:23
<bakkot>
best to have things viewable in view.matrix.org anyway
18:23
<Andreu Botella>
not sure if that tells you anything
18:23
<bakkot>
yeah, it means it can tell the room exists but not get the actual chat history from it, for whatever reason
18:45
<Justin Ridgewell>
Ok, let's make a new channel
18:45
<Justin Ridgewell>
bakkot: If we export the message logs for this channel, can we splice them into the new channel's logs for the bot?
18:46
<littledan>
the big reason why logging was 100% required is to deal with sanctioned entities; I don't think we had any such discussion in this channel before now
18:46
<bakkot>
I can do that manually sure
18:46
<littledan>
let's just set up the new channel
18:46
<Justin Ridgewell>
(Selfishly, I want to refer to some of these chat logs for my performance review)
18:47
<littledan>
lol, I might've heard of a company where you don't have to do all of this self-promotion...
18:49
<shu>
you still gotta deal with performance reviews?
18:49
<shu>
what if you just say to malte, bro, you know me, i do good work
18:50
<Justin Ridgewell>
I don't know the process yet, but I'm preparing as if it's still Google
18:52
<shu>
even google has a new process now
18:52
<shu>
supposedly less work for ICs but more work for managers
19:13
<ljharb>
I’ll set up the channel if that’s helpful
19:16
<Justin Ridgewell>
Go to new channel => https://matrix.to/#/#tc39-async-context:matrix.org
19:16
<littledan>
Hi, thanks for creating this ljharb
19:18
<bakkot>
o/
19:18
<ljharb>
k i think that's all the settings migrated.
19:18
<Justin Ridgewell>
Here's an export of the prior rooms logs ^
19:20
<bakkot>
cool I will get that importat
19:20
<bakkot>
at some point
19:25
<Andreu Botella>
https://matrixlogs.bakkot.com/TC39_Async_Context/2023-02-01 🎉