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:
|
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? |