| 00:01 | <Mathieu Hofman> | * We have a similar thing in https://www.npmjs.com/package/@endo/trampoline |
| 00:34 | <Justin Ridgewell> | Importantly, the TaskRunner's promise.then() (or awaits) would automatically propagate the context that you started the walk from |
| 00:34 | <Justin Ridgewell> | You could code TaskRunner in a way where this breaks, eg, queueing multiple promises but not calling .then() until a much later flush call |
| 00:35 | <Justin Ridgewell> | But that's the reason we have Snapshot, to support that kind of usecase |
| 00:36 | <Justin Ridgewell> | I'd liken it more to doing |
| 00:36 | <Justin Ridgewell> | That cb isn't going to propagate a the creation context automatically |
| 01:34 | <Steve Hicks> | That's exactly right - in most cases where you actually want to retain that initial context, you've already got something else that's seeing to it that it will happen. But for cases where the calls to next() are happening from entirely different contexts, the tracing use case is very often interested in the most recent/immediate cause for the work being done, and other use cases may be as well. For instance, an implicit abort signal could be attached to a request - if the request is doing a small increment of work in a generator, it's reasonable to want that abort signal to control that chunk of work (and if you want the "initialization" signal, you can capture it via a parameter initializer - I agree that's a little non-idiomatic, but it's a lot less non-idiomatic than the yield* helper function NRO showed this morning, which (FWIW) doesn't even work for code before the first yield. |
| 20:14 | <Steve Hicks> | An important distinction between await and yield is that continuations after an await always come directly from the event loop, so there is no meaningful preexisting context, whereas continuations after a yield are immediate/synchronous and have an existing context from whoever called next. So it makes sense to think about them a bit differently. |