| 10:23 | <Andreu Botella> | Don't know about you, but I thought the idea was to implement task attribution on top of AsyncContext, rather than the other way around |
| 10:23 | <Andreu Botella> | but implementing AsyncContext on top of task attribution seems to be what Yoav is proposing |
| 10:29 | <Andreu Botella> | I wonder what the folks from server-side V8-based runtimes think about that |
| 14:08 | <James M Snell> | so the way we handle things in workers... What we actually store using the v8 API is an embedder object wrapped in a js object. We call this embedder object an "Async Context Frame" (or frame for short). That frame maintains a mapping of StorageKey to JS Value. Every AsyncLocalStorage instance (equivalent to AsyncContext) represents one StorageKey. Whenever als.run(...) is called, we create a new frame as a clone of the current and set the new value associated with that key. "Capturing" the current context just means holding a reference to whatever frame is current |
| 14:09 | <James M Snell> | What's nice about this design is that we can (and do) have StorageKey instances that are not associated with a specific AsyncLocalStorage instance |
| 14:11 | <James M Snell> | the values actually stored are also ECMAScript language values |
| 14:11 | <James M Snell> | but those could be externals (js objects wrapping embedder objects) |
| 14:39 | <Andreu Botella> | Hm, I guess if task attribution gets spec'd in the web platform, and it is used for the scheduler API, that would fall under WinterCG |
| 14:40 | <Andreu Botella> | and no matter how that gets implemented in V8, V8-based WinterCG runtimes could handle it the same way as Chromium |
| 14:42 | <Andreu Botella> | so it might not matter that the current async context snapshot is not managed by V8 itself |
| 14:43 | <littledan> | Andreu Botella: What is the difference? Is there some conversation happening somewhere that I'm missing? |
| 14:43 | <Andreu Botella> | Andreu Botella: What is the difference? Is there some conversation happening somewhere that I'm missing? |
| 14:44 | <littledan> | was this linked from somewhere? |
| 14:45 | <littledan> | oh he shared it with us |
| 14:46 | <Andreu Botella> | oh, rereading that I now realized that the doc was framing AsyncContext as a web API rather than a JS built-in, so it wouldn't actually be implemented in V8 if that is accepted |
| 14:46 | <Andreu Botella> | I guess I read it too quickly earlier |
| 14:47 | <James M Snell> | yeah from our perspective (workers) it won't matter to us so long as we can keep using that v8 api to propagate the context |
| 14:48 | <James M Snell> | I rather like the way the API works currently because it makes things super simple for us |
| 14:51 | <Andreu Botella> | in terms of spec layering (which might not correspond at all to how V8/Chromium implement it), if AsyncContext is still spec'd in TC39 rather than in the web specs, task attribution would have to depend on it |
| 15:03 | <littledan> | How did the WebPerf WG meeting to, Chengzhong Wu ? |
| 15:43 | <littledan> | btw the slides say addEventLitener |
| 15:43 | <littledan> | missing an s |
| 15:43 | <littledan> | also I think they should reference OpenTelemetry (maybe with a link to the zone.js library) |
| 19:53 | <littledan> | Both the slides and the explainer make several references to "asynchronous callstack". I would like to discourage folks from using that term, as I think it confusingly implies that we're doing something more similar to Yoav's TaskAttribution. We're not saving a callstack with the whole asynchronous history or building a derivation tree of everything; we're just preserving stuff stashed in .run() through an asynchronous flow of control. |
| 19:57 | <littledan> | 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) |
| 19:58 | <littledan> | in particular: the logical "async stack" can sometimes grow in an unbounded way by accident by just chaining operations. Yoav's system handles this in a lossy way--things can fall off a circular buffer. We're specifically hoping to avoid this by making .run() explicit. |
| 19:59 | <littledan> | [though I guess we do need to decide what to do on stack overflow/excessive growth, which can still happen with .run()] |