Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Parse JSON to Infra" algorithms shouldn't require a current JS realm #625

Open
jyasskin opened this issue Nov 16, 2023 · 5 comments
Open
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest

Comments

@jyasskin
Copy link
Member

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

@jyasskin jyasskin added addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest labels Nov 16, 2023
@annevk
Copy link
Member

annevk commented Nov 17, 2023

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?

@domenic
Copy link
Member

domenic commented Nov 17, 2023

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.

@domenic
Copy link
Member

domenic commented Nov 17, 2023

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?

@ljharb
Copy link
Contributor

ljharb commented Nov 17, 2023

@annevk tbh i have absolutely no idea what "infra" is and why there would ever not be a Realm when JS is executing.

@annevk
Copy link
Member

annevk commented Jul 12, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements needs implementer interest Moving the issue forward requires implementers to express interest
Development

No branches or pull requests

4 participants