| 06:01 | <Chengzhong Wu> | it should be 17 UTC |
| 10:29 | <littledan> | Yeah I see the earlier one as “cancelled” but all calendar integration is broken.. |
| 14:22 | <Sergey Rubanov> | Hello. Is AsyncContext meeting open for everyone? May I invite my colleague joseph@socketsupply.co? |
| 15:25 | <littledan> | Yes, please do! |
| 15:25 | <littledan> | anyone can make contributions to TC39 things online if they sign https://tc39.es/agreements/contributor/ |
| 16:31 | <Justin Ridgewell> | Sergey Rubanov: I added Joseph to the invite, please ensure they sign the IPR agreement before joining |
| 16:32 | <Justin Ridgewell> | See you all in 30min! |
| 16:41 | <Sergey Rubanov> | Sergey Rubanov: I added Joseph to the invite, please ensure they sign the IPR agreement before joining |
| 18:59 | <Mathieu Hofman> | littledan: in the meeting you mentioned you still believe there is a way to fast path task termination with reference counting when snapshots are not in play. While I have to think more about this, I have a few clarifying questions:
|
| 19:36 | <Mathieu Hofman> | To clarify, if a program adds a reaction to an unresolved promise, then the program drops the resolvers, there is no way for the pending reaction to ever be called. If that reaction was the last thing that captured the async context, would that async context be deemed terminated? |
| 19:40 | <Mathieu Hofman> | Basically from my point of view, either we explicitly exclude GC from decrementing task termination counters, resulting in "pending" task that are in fact no longer pending (regardless of the usage of snapshot or not), or we admit that task termination is intrinsically tied to GC, thus making the user land process for task termination observation simply be a FinalizationRegistry registration of an object used as context value. If I'm missing something, please correct me. |
| 20:28 | <littledan> |
Yeah that's a possibility. Another possibility is that it's not exposed to JS. I don't see any meaningful change in the implementation work required by these two options, but maybe I'm missing something |
| 20:30 | <littledan> |
To be clear, I think this would amount to internal-only snapshot calls leading to the appropriate reference counting operations, and just omitting user calls of snapshot operations. Fundamentally the same thing but maybe less risky because the counts can't be misused/left hanging unless the browser does that. And this would mean that we wouldn't have to muck up the snapshot API with a reference counting concept. |
| 21:07 | <Mathieu Hofman> | As I mentioned above, I think that whether a user API for snapshots is involved or not has no bearing on the problem. If a pending promise with reaction can be collected without the reactions being executed, that means task termination is intrinsically tied to GC. If these resolver-less promise cannot be collected, that means these tasks will leak / never terminate. If task termination is tied to GC, we would be opposed to a user exposed API specific to task termination, as we are invested in keeping gc observability to the existing WeakRef / FinalizationRegistry feature. |
| 21:27 | <littledan> | About the GC tie-in, I completely disagree. If task termination does necessarily tie into GC, then I agree with you and others that we should keep it far away from AsyncContext and not add it in TC39.
Remember that a Promise captures a snapshot when you .then it, not when the Promise is created. If that promise never resolves... well, then that task is left hanging and never terminates. Maybe there should be some kind of event to notify folks when that happens, but I don't think it's the normal termination event, or should ever be treated as similar to one. |
| 21:27 | <littledan> | Allocating a resolver-less promise doesn't make any particular task hang |
| 21:28 | <Mathieu Hofman> |
I guess we agree? I'm saying I don't want a TC39 API for AsyncContext task termination if it would ultimately allow to observe GC |
| 21:28 | <littledan> | I 100% agree about how we should limit GC observability |
| 21:29 | <littledan> | yeah sounds like we agree |
| 21:29 | <littledan> | I'm just disagreeing that we should do anything in particular about GC'd promises |
| 21:29 | <littledan> | or that it'd make any kind of sense to |
| 21:31 | <Mathieu Hofman> | I think my question above was: You create a promise, add a reaction (.then it), then drop the resolvers. What happens to the task captured in the reactions? Is it ok for the task to be considered "pending" forever? |
| 21:31 | <littledan> | yeah, my answer is, "yes, it's pending forever" |
| 21:32 | <littledan> | I had the impression that someone was claiming otherwise, that we'd have to let GC terminate it |
| 21:32 | <littledan> | I think for some applications around saving memory, you do want something-or-other with GC around tasks to do something, but this is a distinct problem from the accurate task termination notification |
| 21:35 | <littledan> | BTW I also wanted to mention: I got a chance to discuss AsyncContext with Anne vK at the Web Engines Hackfest, and explained the problems around what the model is for which snapshot is restored, and how this is non-trivial for events. He was generally not negative about the proposal, just expressing that this needed to be worked out. So I think it will be good for Ms2ger and Yoav to get in touch with Anne at some point, now that he has this basic context. |
| 21:53 | <Mathieu Hofman> | If task termination is strictly about counting the number of reactions added (increment), and executed (decrement), then I am ok with an AsyncContext specific API from a technical pov, however I am doubtful of the usefulness of such a user-land API, and warry of the surprises it would cause (aka question like why is my task never terminated) |
| 21:55 | <littledan> | I'm confused; why do you think this will be a common case? |
| 21:55 | <littledan> | Some use cases for this capability are linked in the top of this document: https://docs.google.com/document/d/1yQy8RNeGXLr99bNpy-7tA1Ch7wN0piekp_-JwxC8FtA/edit |
| 21:56 | <Mathieu Hofman> | well Snapshot for one case. If you create one, basically you can never terminate the task |
| 21:57 | <Mathieu Hofman> | unless we make the snapshot disposable, which would nerf its .run |
| 21:57 | <littledan> | right, this would require that we change the snapshot API |
| 21:57 | <littledan> | which is why I think we should think it through right now |
| 21:58 | <littledan> | we could end up deciding against wanting to support this, but it's not a straightforward thing to add later if we build off the current API, for exactly this reason |
| 21:58 | <littledan> | One way it could work: By default, an AsyncContext.snapshot is nerfed in its first .run, but you can also allocate a "persistent" one which will stay there until you do Symbol.dispose on it. (Obviously this can cause leaks...) |
| 22:54 | <Thomas Nguyen> | This is a first draft of what I got from the Wiz team. Going to talk to the Angular team tomorrow to see if they have anything else |
| 22:54 | <Thomas Nguyen> | https://docs.google.com/document/d/1hsGuccEtXiTGW9Xok0jhMPhfPtVCrZz-WaEoL1d8bI0/edit?usp=sharing |
| 22:57 | <littledan> | This is really great! One thing I think we should consider more: If we expect AsyncContext to be used for reactivity tracking (or, React hooks), that is quite a hot path, and it would be good to ensure that this is practical for implementations to meet the implied performance expectations. Given the advanced progress on a V8 proof-of-concept, I'm hopeful that we can actually experiment here in the next few quarters. |
| 22:59 | <littledan> | also: can you open-source Wiz? 🥺 |