Open jyasskin opened 9 months ago
We could also setup a bare bones synthetic environment. Not sure what I'd prefer.
@syg @ljharb did you all think about this at some point perhaps?
IndexedDB does "a user agent-defined Realm", albeit with structured clone which is a bit different since it takes a realm argument instead of using the ambient current realm: https://w3c.github.io/IndexedDB/#add-or-put
I think we can do the same thing; just push a user agent defined realm on the stack, and pop it at the end.
If we did want to refactor to not have any realm dependency, we could basically pull out steps 4-5 of https://tc39.es/ecma262/#sec-json.parse , and then crawl the ParseNode tree instead of our current strategy of crawling the object tree. I have a lot less experience working with ParseNodes in specs, but it's at least conceivable that this is about the same amount of work as what we currently do?
@annevk tbh i have absolutely no idea what "infra" is and why there would ever not be a Realm when JS is executing.
For some callers another problem here is that this algorithm can throw, but I think some callers also depend on that. So maybe that requires its own wrapper.
What problem are you trying to solve?
Parse a JSON string to an Infra value and parse JSON bytes to an Infra value convert Infra types to Infra types, but because they use %JSON.parse% internally, they implicitly expect there to be a current realm, which means they strictly can't be called from in parallel.
Actual implementations can parse JSON to an internal representation without using the JS engine, so specs should be able to also.
What solutions exist today?
It's often possible to parse the JSON before going into parallel, or to bounce through the main thread if the JSON arrived from a parallel fetch, but these can complicate the spec algorithms.
How would you solve it?
The simplest way might be to say that even though these algorithms are specified as if they used a JS realm, we assert that they're usable without a current realm. This leaves the exact details a bit imprecisely specified, but the bits that lose their detailed meaning inside the JS spec don't actually matter to the result of the algorithm.
The other solution would be to respecify JSON parsing purely in terms of Infra concepts, which is going to be an uncomfortably big patch.
Anything else?
No response