| 02:46 | <Chengzhong Wu> | How did the WebPerf WG meeting to, Chengzhong Wu ? |
| 03:08 | <littledan> | Are there notes? |
| 03:09 | <Chengzhong Wu> | It should be published shortly at https://w3c.github.io/web-performance/meetings/ |
| 03:10 | <Chengzhong Wu> | Not published yet. |
| 03:12 | <littledan> | The use cases there are very interesting. Maybe it would be useful to link that deck from the readme |
| 03:12 | <littledan> | And possibly go into it at TC39 as well if there is skepticism raised |
| 03:13 | <littledan> | (Could be pasted on as bonus slides?) |
| 03:24 | <Chengzhong Wu> | yeah, we can bring the use case slides up when needed. |
| 03:25 | <Chengzhong Wu> | So I'd suggest saying, "asynchronous flow of control", or especially better if we say something more concrete, e.g., "Annotating logs with information related to a particular logically related series of operations, even with callbacks and promises" (or, maybe there's a better way to put that, idk) |
| 08:26 | <Yoav Weiss> | Rough minutes are at https://docs.google.com/document/d/1wO7mbGr6f3tDnEWAaMSVI0bMeEHIdcLbAKeOQe-Zh4U/edit#heading=h.1sx1vjpi65co |
| 08:28 | <Chengzhong Wu> | The document is not public -- access requested |
| 08:28 | <Yoav Weiss> | apologies! should be now |
| 08:34 | <Yoav Weiss> | If I can try to summarize the feedback: RUM providers would be very interested in being able to keep track of operations that are a result of a certain AsyncContext |
| 08:35 | <Yoav Weiss> | e.g. "This element timing entry is a result of a user click on element X" is something they'd love to be able to surface to their customers |
| 08:36 | <Yoav Weiss> | It was unclear from the conversation if the current API enables them to achieve that without over-instrumentation of their customers' code (which they prefer not to do) |
| 08:38 | <Yoav Weiss> | But maybe magicaly surfacing the AsyncContext data in PerfObserver entries can help them do that if they wrap addEventListener callbacks |
| 08:50 | <Chengzhong Wu> | Yeah, this can be another interesting topic that we can discuss about. Node.js provides diagnostics_channel for library providers to expose certain events, for example: https://github.com/nodejs/undici/blob/main/docs/api/DiagnosticsChannel.md. |
| 08:54 | <Chengzhong Wu> | I don't think async context is the exact only tool helping in this problem. |
| 09:00 | <Yoav Weiss> | https://docs.google.com/document/d/16HstQ6yHWMhFHflrpnKTeH0FDGxpQ8fKWqbA1mos3Ag/edit#heading=h.9g3dvhcn9qro as I jotted down what I think a JS side impl may look like from my perspective |
| 09:01 | <Yoav Weiss> | (dunno much about the implementation complexity of actually doing that in V8) |
| 11:43 | <Andreu Botella> | Is AsyncContext.wrap only needed in userland JS with things like non-builtin promise libraries? |
| 11:44 | <Andreu Botella> | I was mostly thinking of it from an implementation perspective where you have to wrap when enqueuing promise jobs and other tasks, so I hadn't really thought about how it'd be used in userland |
| 11:45 | <Andreu Botella> | but I guess it's only really useful at that same level of abstraction |
| 11:54 | <James M Snell> | Yoav Weiss: I think what you describe there matches what we're doing in workers. We do have cases where we gave to grab a strong reference the current frame (taskscope in your proposal) and enter it manually (for instance, when queuing unhandled rejection events, or setTimer/setInterval... We also use it for tracing internally). If we had to implement task attribution apis in the runtime I don't think that's too much of a problem tho I would need to see more of what's involved. |
| 13:01 | <littledan> | and no matter how that gets implemented in V8, V8-based WinterCG runtimes could handle it the same way as Chromium |
| 13:01 | <Andreu Botella> | oh, that's right, Electron |
| 13:06 | <James M Snell> | Yep that's exactly it. As long as embedders can capture a reference to the entire frame at a point in time when necessary. |
| 13:07 | <James M Snell> | Having v8 manage it for us is best |
| 17:26 | <Justin Ridgewell> | It was unclear from the conversation if the current API enables them to achieve that without over-instrumentation of their customers' code (which they prefer not to do) |
| 17:28 | <Justin Ridgewell> | Is |
| 17:29 | <littledan> | right, any time you have an API which takes a callback and the API logically "schedules" that callback, it might be a good idea to use .wrap() |
| 17:34 | <Justin Ridgewell> | So I'd suggest saying, "asynchronous flow of control", or especially better if we say something more concrete, e.g., "Annotating logs with information related to a particular logically related series of operations, even with callbacks and promises" (or, maybe there's a better way to put that, idk) |
| 17:34 | <Justin Ridgewell> | I don't think the we imply that we're capturing the actual function calls anywhere |
| 17:44 | <Justin Ridgewell> | Particularly for cases like await promiseFromAnotherContext, is the context after that await the one from the promise? That would follow control flow, but describing it as the the callstack clears up that confusion |
| 17:44 | <Justin Ridgewell> | And, it's easy to explain why the context contains a certain value, just poke up the callstack in the dev tools |
| 18:13 | <littledan> | I don't think the we imply that we're capturing the actual function calls anywhere |
| 18:14 | <littledan> | Anyway I am just trying to help you make things are clear, it’s your call how to present it |