| 15:33 | <littledan> | Justin Ridgewell: Could you describe the semantics you're thinking of in the cross-realm case? |
| 15:33 | <littledan> | (or if there's some JS implementation, point me to it) |
| 16:03 | <Justin Ridgewell> | It would require the polyfill to have access to the other realm |
| 16:09 | <littledan> | Sure, this is a general thing about polyfills that makes them tend to not be spec-complaint |
| 16:09 | <littledan> | What are the semantics that you want Realm-separated wrap to have at runtime? I just don't know what you're proposing. |
| 16:10 | <littledan> | like, would Promise.prototype.then do a Realm-separated wrap or a cross-Realm one? |
| 16:12 | <littledan> | without Realm separation, each microtask queue item can have a single word added to it, which is "what is the whole group of AsyncContexts to restore during this microtask queue item". If we're being Realm-specific... I don't actually know what this should contain. |
| 16:13 | <Justin Ridgewell> | I don’t understand how they would be different. It would still be a single pointer to a map. |
| 16:13 | <littledan> | OK, but the map would contain only the async contexts that are in the Realm that called then? |
| 16:14 | <littledan> | so, synchronously, you could call otherRealmContext.get() and get that value, but it'd be lost when you restore the microtask queue item |
| 16:14 | <littledan> | that's the observable difference of being realm-separated |
| 16:14 | <littledan> | right? |
| 16:15 | <Justin Ridgewell> | Isn’t that intrinsic to then? Like which globals and environment is it going to resume with? |
| 16:16 | <littledan> | sure but I imagined this being different from that (since synchronously you can get multiple Realms' AsyncContext things) |
| 16:16 | <littledan> | so, synchronously, you could call |
| 16:17 | <Justin Ridgewell> | Yes, if we choose per realm. |
| 16:18 | <littledan> | OK, now I understand. And so what is the advantage of these semantics, of partitioning the AsyncContexts in this way? |
| 16:20 | <Justin Ridgewell> |
|
| 16:20 | <Justin Ridgewell> | There’s no real benefit to it this way, it’s just easy |
| 16:24 | <littledan> | One thing it consider is that, in some implementations, this data structure gets a bit complex since you might want to scale up to a large number of .run calls nested in each other without that being quadratic (so you don't want to have to clone the whole map for each .run call). But I'm not sure whether this argues for Realm-partitioned or global (maybe it's the same?) |
| 16:26 | <littledan> | oh, also, how should we handle AsyncContexts that aren't in any Realm at all because they're implicitly set by other built-in libraries (e.g., web standards)? |
| 16:26 | <Justin Ridgewell> | I think it’s much more likely that you’ll have many snapshots happening than many nested runs happening, so I prioritized zero-copy snapshots |
| 16:27 | <littledan> | yes, snapshots must be extremely cheap, that's for sure |
| 16:27 | <littledan> | I don't think one thing excludes another. A classic purely functional map (like Clojure has) would work for what I described. |
| 16:28 | <littledan> | (snapshots are also free there) |
| 16:28 | <Justin Ridgewell> | Maybe we could add a multi-run behavior where many contexts are set, to avoid N clones of the map? |
| 16:28 | <littledan> | what do you mean? |
| 16:29 | <littledan> | oh, a JS-visible API for that? |
| 16:29 | <Justin Ridgewell> | AsyncContext.runMultiple([a, val, b, otherVal]) |
| 16:29 | <Justin Ridgewell> | So a and b are set without 2 clones |
| 16:29 | <littledan> | I don't think this would remove the potential demand for multiple calls of run being more efficient. Also I'm speculating here; I can't think of when it'd make sense to do that very deeply |
| 16:30 | <littledan> | Generally it should be separate pieces of code which ask for different variables (otherwise they should consolidate into one) |
| 16:31 | <Justin Ridgewell> | I don't think one thing excludes another. A classic purely functional map (like Clojure has) would work for what I described. |
| 16:31 | <Justin Ridgewell> | You’ve had to flatten the chain, but maybe that can happen in a GC step |
| 16:31 | <littledan> | Yeah, this is why you wouldn't use a linked list but instead a functional map. Will find a link... |
| 16:33 | <littledan> | https://clojure.org/reference/data_structures#Maps |
| 16:34 | <littledan> | anyway probably just a JS Map is good enough in practice; I just wouldn't want to rule out using this theoretically more efficient mechanism in case things come up. But I think this would be possible and doesn't relate to the use of Realms. |
| 16:35 | <littledan> | see Chris Okazaki's classic thesis for an overview of this topic, summary at https://en.wikipedia.org/wiki/Purely_functional_data_structure |
| 16:38 | <littledan> | oh, also, how should we handle AsyncContexts that aren't in any Realm at all because they're implicitly set by other built-in libraries (e.g., web standards)? |
| 16:53 | <littledan> | OK, so I want to dig into this part. This is core to my agenda of linking AsyncContext with Yoav Weiss 's work, which is around built-in variables (which I believe should be propagated in the identical way to AsyncContext) |
| 17:11 | <Justin Ridgewell> | 🤷♂️. Is we specify the storage as per-agent, do we need to do any further work to integrate the browser context? |
| 17:37 | <littledan> | yeah I'd prefer per-agent; if we do per-Realm, I'm not sure how it should work |
| 17:38 | <littledan> | I guess you convinced me that it wouldn't be harder to implement per-Realm and that the semantics can be defined; now this is potentially the thing to rest the decision on |
| 20:33 | <Justin Ridgewell> | Just got out of a meeting with the SES folks, and they're supportive of the proposal now |
| 20:34 | <Justin Ridgewell> | Well, MM in particular, but of the 2 meetings I've had with SES and OCAP folks, there aren't any objections raised |
| 20:35 | <littledan> | Just got out of a meeting with the SES folks, and they're supportive of the proposal now |
| 20:36 | <littledan> | Could you elaborate a little more on their thoughts? |
| 20:36 | <littledan> | Did it rest on the per-Realm vs cross-Realm aspect we were discussing above? |
| 20:37 | <Justin Ridgewell> | No, not at all, they're looking at it from the OCAP language model |
| 20:37 | <littledan> | cool |
| 20:37 | <Justin Ridgewell> | While this does give new powers (and there's an implicit message passing), they're ok with it. |
| 20:38 | <Justin Ridgewell> | I think we'll need to discuss with the browser folks to decide on realm-ness |
| 20:42 | <Justin Ridgewell> | 🌶️ Also Crockford wants us to stop adding new features to the language |
| 20:43 | <Kris Kowal> | Crockford wants us to take features away, really. |
| 20:43 | <Kris Kowal> | Oh, he was at friam! Of course he was. |
| 20:44 | <Justin Ridgewell> | Yup |
| 20:44 | <Justin Ridgewell> | We'll have a video of it uploaded eventually |
| 21:10 | <littledan> | Crockford wants us to take features away, really. |
| 21:11 | <Kris Kowal> | Yes. |
| 21:11 | <littledan> | I think we'll need to discuss with the browser folks to decide on realm-ness |
| 21:11 | <Kris Kowal> | Crockford has gone from specifically grumpy to generally grumpy. |
| 21:12 | <littledan> | Crockford has gone from specifically grumpy to generally grumpy. |
| 21:14 | <Kris Kowal> | Same as anyone else and in the same way. :-) |
| 21:16 | <littledan> | Oh, he was at friam! Of course he was. |
| 21:18 | <Kris Kowal> | There was an ocap research group meeting at a company called Agorics in the 90s. The company was acquired by Microsoft and the team scattered, but has continued to meet every Friday morning ever since. Folks as noteworthy as the late Carl Hewitt were regulars at Friam. |
| 21:19 | <Kris Kowal> | Might have started at Xeorx PARC. I’m not sure. |
| 21:20 | <littledan> | oh, this was the audience that Justin brought this proposal to? |
| 21:21 | <Kris Kowal> | Yeah, MarkM wanted to share the same material from the SES meeting with this group for more eyes. |
| 21:21 | <littledan> | SGTM, are there further eyes in the ocap world we should be seeking here, or is this considered the highest body? |
| 21:25 | <Kris Kowal> | Idk about highest, but it’s certainly the centermost. |
| 21:55 | <Justin Ridgewell> | Yah, Mark wanted to discuss with OCAP folks because JS is a subset of the OCAP language model |
| 21:56 | <Justin Ridgewell> | We didn't dive deeply into the JS semantics, it was pretty general discussion on programming |