2023-09-04 [12:06:26.0277] Can anyone review this? https://github.com/tc39/proposal-async-context/pull/53 2023-09-05 [11:03:05.0324] https://docs.google.com/document/d/1oPJj7k0txm0p54lKQ0ngS8ifEU1WGDhyKLbZmpfckJg/edit [11:03:17.0832] Draft slides: https://docs.google.com/presentation/d/12A3LYlqgzmqRqE0mJ47GRWB6uKlqoFXiWE9gsxpRje4/edit#slide=id.g27aef1f6697_0_117 [16:52:11.0046] > <@legendecas:matrix.org> Draft slides: https://docs.google.com/presentation/d/12A3LYlqgzmqRqE0mJ47GRWB6uKlqoFXiWE9gsxpRje4/edit#slide=id.g27aef1f6697_0_117 This is a great start! 2023-09-06 [17:02:09.0064] > <@legendecas:matrix.org> https://docs.google.com/document/d/1oPJj7k0txm0p54lKQ0ngS8ifEU1WGDhyKLbZmpfckJg/edit This is a good writeup. It should probably also speak to the issue Andreu raised above: when you call .then(cb) and get a new promise, or when you do an await inside of an async function with no catch, the *resulting* promise is the one which has the unhandled rejection, and its rejection site is the one that is used. In those two cases, the rejection site is the place is the same as the creation site. 2023-09-07 [08:33:13.0557] Hey, I think I might forgotten to mention it here, but we're having a breakout session in TPAC next Wednesday about HTML integration of AsyncContext: https://github.com/w3c/tpac2023-breakouts/issues/39 [08:33:50.0019] at 12:15 PM UTC+2 [08:35:00.0601] it's open to join remotely, but I'm not sure if there's a link anywhere yet 2023-09-13 [00:44:29.0937] Hey, reminder that the AsyncContext breakout session at TPAC starts at 12:15 PM CEST (2h 30m from now). You will find the Zoom links at https://www.w3.org/events/meetings/477d72e8-6beb-427a-a320-f77e97aca326/ 2023-09-14 [19:57:04.0947] Yesterday’s AsyncContext breakout unfortunately failed to gather the participation of many stakeholders who we were trying to bring together for discussion. Are we going to have a replacement discussion during this week on the sidelines of TPAC? How is scheduling that going? [19:59:05.0495] That's unfortunate. I had been planning to join but just couldn't make it work with the timezone offset. Will definitely try to make the next one. [20:39:29.0921] Would’ve been good to have you but the real missing parties were the browsers. We will try to catch up with them on the sidelines somehow [23:26:19.0849] There were a lot of other breakout sessions going on at the same time, and I don't blame anyone present at TPAC from not attending [23:26:38.0639] I will blame everyone who couldn't join remotely because of the timezone /j 2023-09-15 [20:24:51.0796] We had a very good conversation at the end of the day yesterday with Anne VK (Apple), Ollie (smaug from Mozilla), Yoav, Domenic (Google), and Andreu about AsyncContext. Some results: - everyone came to understand each other better, eg about what AsyncContext is and why it is useful - smaug continues to be concerned about memory usage in an extremely general way. I am pretty convinced that no WeakMap in the mix will just fix things here, and no one really defended that particular mechanism. I don’t see a way to follow up on this concern as it is very general, just based on experience of websites doing memory leaks. It is important that devtools gives good mechanisms to see what closes over what, including asynccontext snapshots, to help people debug memory leaks. - Googlers have repeatedly raised this question of the appropriate venue to do this work. Yoav and I agreed that it could be done in either place and it’d be fine—there just aren’t huge technical differences. No one had a strong argument to push for a change, and Apple and Mozilla didn’t seem opinionated one way or another, so we will just leave things as is for now. - Domenic was concerned that task attribution didn’t correspond to AsyncContext because he thought that task attribution would use caller semantics rather than register semantics; Yoav clarified that it actually often needs register semantics. We will need to do a case analysis to confirm, but there continues to be cautious optimism here about how asynccontext and task attribution need the same sort of thing. - As far as what the semantics should be for when to use caller vs register semantics: Domenic pushed for a strong default that everything uses register semantics, except for a limited list of exceptions that we will figure out. I like this idea. He tried to get a read from other browsers about whether this makes sense for them, but they weren’t prepared to answer. Yoav isn’t sure whether we can do this at the callback level due to previous evidence of overhead, but that was coupled to creating task attribution nodes and we need to measure this separately. We will need to do this case by case study of which web APIs should use caller vs register semantics to confirm—no one feels like they have a complete picture. [20:25:22.0875] * We had a very good conversation at the end of the day yesterday with Anne VK (Apple), Ollie (smaug from Mozilla), Yoav, Domenic (Google), and Andreu about AsyncContext. Some results: • everyone came to understand each other better, eg about what AsyncContext is and why it is useful • smaug continues to be concerned about memory usage in an extremely general way. I am pretty convinced that no WeakMap in the mix will just not fix things here, and no one really defended that particular mechanism. I don’t see a way to follow up on this concern as it is very general, just based on experience of websites doing memory leaks. It is important that devtools gives good mechanisms to see what closes over what, including asynccontext snapshots, to help people debug memory leaks. • Googlers have repeatedly raised this question of the appropriate venue to do this work. Yoav and I agreed that it could be done in either place and it’d be fine—there just aren’t huge technical differences. No one had a strong argument to push for a change, and Apple and Mozilla didn’t seem opinionated one way or another, so we will just leave things as is for now. • Domenic was concerned that task attribution didn’t correspond to AsyncContext because he thought that task attribution would use caller semantics rather than register semantics; Yoav clarified that it actually often needs register semantics. We will need to do a case analysis to confirm, but there continues to be cautious optimism here about how asynccontext and task attribution need the same sort of thing. • As far as what the semantics should be for when to use caller vs register semantics: Domenic pushed for a strong default that everything uses register semantics, except for a limited list of exceptions that we will figure out. I like this idea. He tried to get a read from other browsers about whether this makes sense for them, but they weren’t prepared to answer. Yoav isn’t sure whether we can do this at the callback level due to previous evidence of overhead, but that was coupled to creating task attribution nodes and we need to measure this separately. We will need to do this case by case study of which web APIs should use caller vs register semantics to confirm—no one feels like they have a complete picture. 2023-09-19 [10:05:28.0690] Chengzhong Wu: Hey, we can't hear you [10:06:02.0582] yes we were talking [10:06:22.0108] Yeah... I can not hear you too. I'm going to re-join the call. 2023-09-27 [17:57:17.0474] Chengzhong Wu: Are we skipping Slide 8 (async functions and promise rejections)? [17:58:22.0806] I think that we can come back to this slide when the time allows [18:16:05.0925] yeah I agree with skipping slide 8 [18:30:57.0636] Sorry about this; we should get our story straight among ourselves before the next presentation [18:32:03.0605] The slide mentioned specifically that web APIs need `run` in the context of task attribution [18:32:16.0244] maybe I should've made it clearer that it was Variable.p.run [18:32:49.0124] I guess out of context that's not clear [18:32:49.0217] fundamentally, Justin probably should've been aware of what was being presented, and I should've given feedback about not emphasizing the concerns raised on the last couple slides (since they were just not relevant or representative) [18:33:03.0993] it'd be OK if the audience is confused but we shouldn't get confused among ourselves [18:33:31.0133] That slide was added after our last meeting, so I wasn't aware until now. Sorry [18:33:35.0015] I mean, obviously the audience shouldn't be confused either [18:33:53.0767] yes, the last couple slides were added since I last saw it, sorry [18:34:30.0157] I added them sometime last week, maybe Thursday, although I was modifying them earlier today / yesterday [18:35:30.0972] yeah if you could just ping the channel to ask for reviews, then it'd be helpful [18:36:17.0220] the slides weren't incorrect, we just have to think about how to explain things best [18:46:07.0714] can we make sure AsyncContext becomes stage 3 before V8 decides to get rid of CPED [18:57:50.0482] Umm... Gets rid of CPED...? Is that at risk? [18:58:10.0864] V8 doesn't seem happy with it [18:58:26.0718] Workers is absolutely relying on that API right now. That would break us [18:58:47.0025] James M Snell: i don't think removal of the expressivity is at risk, but the current implementation leaves something to be desired so the implementation might change [18:59:23.0380] Impl changing is fine. We can adjust to impl changing. But we absolutely depend on that API [19:00:16.0094] We can fallback to promise hooks if we absolutely need to buy obviously would rather not [19:00:16.0246] noted [19:00:30.0103] Shu seems to be expressing that a conclusion hasn't been reached yet, rather than being uniformly unhappy. I think the best thing we could do is move forward with our design doc for review by the V8 team. [19:00:48.0520] Let me know if I can help [19:01:35.0563] We use CPED in our ALS impl but also under the covers for propagating trace spans across async boundaries. [19:01:55.0801] We have a c++ level API wrapped around it that we use for both purposes [19:02:34.0932] See also this review on an CL for CPED to support thenables: https://chromium-review.googlesource.com/c/v8/v8/+/4674242/comments/8fa12f12_eef7ac70 [19:03:48.0259] though IMO Blink is not gonna be happy with CPED being removed without an alternative [19:05:17.0413] Fwiw, even once AsyncContext is done, we'll need a c++level API for accessing it as we have areas where we have to manually propagate context over other async boundaries (like our timers impl). We don't care what the actual API is as long as it's available and we have time to move over to it. E. G. Please don't drop CPED without having the replacement in place first [19:05:35.0917] yes, this is part of the draft design doc. We just need to finish that doc. [19:05:46.0295] and the draft implementation has this already [19:06:30.0929] when prototyping the Blink integration I noticed the C++ API we initially drafted isn't great, but that's something that we can iterate on [19:07:08.0893] Certainly, C++ native APIs of async context would definitely a requirement for hosts [19:07:14.0061] * Certainly, C++ native APIs of async context would definitely be a requirement for hosts [19:07:20.0865] btw Luca from Sentry expressed interest in joining this effort. I'll just invite him to this room? [19:07:34.0430] > <@littledan:matrix.org> btw Luca from Sentry expressed interest in joining this effort. I'll just invite him to this room? Definitely, please [19:07:40.0527] Happy to review the API we implemented once the top. It has warts but it works well for us [19:07:59.0908] "once the top"? [19:07:59.0920] * Happy to review the API we implemented over the top. It has warts but it works well for us [19:08:06.0060] Typo [19:08:09.0040] thanks for correcting [19:21:58.0636] Let's write a good summary/conclusion for the TC39 topic