06:29
<littledan>
I agree that it would be nice to make some basic usages more prominent in the readme
06:45
<littledan>
Basically if the readme could be more like the first half of the previous presentation pasted together with the presentation from next meeting
09:40
<Yoav Weiss>
RE https://github.com/tc39/proposal-async-context/issues/52, I'm now thinking if GC times may not be good enough for my immediate use case
09:40
<Yoav Weiss>
and potentially something we can more tightly define once it's actually required
14:21
<littledan>
Garbage collection is not an option here IMO
14:45
<Yoav Weiss>
I agree it's not an option for timestamps
14:45
<Yoav Weiss>
as GC can be arbitrarily late
14:46
<Yoav Weiss>
but it can be an option (I think) for TaskAttribution's container management
21:09
<Justin Ridgewell>

I think we have to deal with GC in a few cases:

  1. AsyncContext.wrap()
  2. new Promise(() => {}) (permanently pending promise)
21:10
<Justin Ridgewell>
There's an optimistic fast path for promises that resolve (we can decrement the pending counter as soon as that happens), but promises aren't guaranteed to resolve ever.
21:10
<Justin Ridgewell>
So we're stuck waiting for GC the promise
21:17
<Mathieu Hofman>
Which will be fun given how leaky promises are in most engines these days
22:00
<littledan>
Yeah I think we want to count outstanding tasks/micro tasks
22:47
<Mathieu Hofman>
We agree that's an optimization, right?
22:53
<littledan>
I don’t think gc vs exact timing is an optimization; I think it is sort of different semantics
22:53
<littledan>
There are certain use cases that really only work with exact timing (not just perf metrics but also Angular’s zone.js usage)
22:54
<littledan>
We just shouldn’t build these features in a way which takes advantage of finalizers
23:51
<Mathieu Hofman>
For a userland API how do you reconcile that with the fact that task termination is intrinsically tied in some cases to the collection of user held and observable objects?