| 05:10 | <Andreu Botella> | Hey, I was looking for some issue in the repo about why we made AsyncContext per-agent rather than per-realm, and I remember some SES concern playing into that, but there doesn't seem to be any issue on the AsyncContext repo about that |
| 05:10 | <Andreu Botella> | is that discussion logged somewhere? |
| 06:17 | <Chengzhong Wu> | https://github.com/tc39/notes/blob/main/meetings/2023-01/feb-01.md#conclusion |
| 06:19 | <Chengzhong Wu> | The conclusion was captured back in notes of 2023-01 |
| 08:45 | <Mathieu Hofman> | My understanding is that, thanks to the transform into continuation passing style to explain why async context is not really introducing observable global mutable state, it also shows that the context info is shared any time a call is made. Since calls can happen cross realm, it means that when modeling async context as a global state, that has to be shared for the whole agent. |
| 08:50 | <Mathieu Hofman> | Looking at the notes, Mark actually was/is concerned about speccing AsyncContext in terms of global mutable state, but that's a general concern, and making it cross realm is even scarier. I suspect however that speccing it in terms of continuation passing would be too large of a change in the spec. |
| 17:30 | <littledan> | Maybe we can specify AsyncContext without global mutable state when anything else about JS execution is specified that way… |
| 18:44 | <Mathieu Hofman> | I'm confused. What is currently specified as global mutable state besides the symbol registry? |
| 18:51 | <littledan> | The execution context? |
| 18:52 | <littledan> | AsyncContext would attach to that |
| 18:53 | <littledan> | The important thing is that it is used in a structured way; the editorial point is unactionable unless we change a lot more stuff |
| 18:54 | <littledan> | we push things onto the execution context stack... that is a mutation |