| 17:28 | <littledan> | https://github.com/tc39/proposal-async-context/pull/53/files |
| 18:01 | <Andreu Botella> | I just realized that making HostCallJobCallback not swap the snapshot makes it so we'd need to swap it in CleanupFinalizationRegistry to preserve the behavior in the current spec |
| 18:01 | <Andreu Botella> | and with Justin's suggestion in https://github.com/tc39/proposal-async-context/pull/41#pullrequestreview-1348745850 to store the snapshot in the PromiseCapability, we'd need to add a slot to FinalizationRegistry for the snapshot |
| 18:02 | <Andreu Botella> | so maybe we should discuss if that is needed/expected, since it wouldn't fall naturally out of how HostCallJobCallback works anymore |
| 20:45 | <Mathieu Hofman> | Oh interesting, I hadn't realized that FinalizationRegistry is the only case of a TC39 "event callback". I would definitely expect the context of that callback to be the one that created the FinalizationRegistry |
| 20:52 | <Andreu Botella> | yeah, that makes sense |
| 21:30 | <Mathieu Hofman> | arguably there is another context that would make sense here: the context at the time of the finalizationRegistry.register call |
| 21:30 | <Mathieu Hofman> | in which case the context would be stored on the FinalizationRegistry cell instead of the FinalizationRegistry instance. what would make the most sense ? |
| 21:32 | <Mathieu Hofman> | I personally think that causing an AsyncContext's lifetime to depend on some value getting collected is a source of issues |
| 21:33 | <Mathieu Hofman> | and if programs want to do that, they can create a snapshot and use it as FinalizationRegistry held value |