[WIP] feat(web): Serializable platform objects

[andreubotella]

This is a prototype implementation of the serializable part of the API in #12067 (comment), to gather feedback.

[andreubotella]

For context, since the registered interfaces are stored in JsRuntimeState, any interfaces that are registered during bootstrap will not survive when the snapshot is loaded. That's why ext/web/00_interfaces.js is necessary.

[andreubotella]

@lucacasonato @kitsonk @bartlomieju PTAL

This currently only makes DOMException serializable (which doesn't have WPT tests, oddly enough), since that's the simplest example of serializing a platform interface that we implement. Once I get some reviews on this PR, I'll work on serializing Blob and File – transfers will probably be left for 1.17.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[andreubotella]

Not stale, this is pending on denoland/rusty_v8#862.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[andreubotella]

Still pending on denoland/rusty_v8#862. That PR is in turn pending on me figuring out if the generics for the new scopes make sense together with the rest of scopes.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[aapoalas]

Requires rebase, and of course a fair bit of work. However, this seems to be a pretty awesome feature that I hadn't even fully understood existed on the Web platform. Transferable streams?! That's proper multithreading right there, innit?

I would love to see work on this, and not only from @andreubotella 's side.

[bartlomieju]

@andreubotella I know you are very busy, but if you find some time, could you please write a few pointers what still needs to happen for this PR to be landable?

[andreubotella]

@andreubotella I know you are very busy, but if you find some time, could you please write a few pointers what still needs to happen for this PR to be landable?

I haven't looked too much at this PR lately, and some of the design constraints I was working under in 2021 no longer apply. The main one is that, in order to be able to customize serialization for an object, it had to have embedder fields (i.e. it had to be created through Deno.core.createHostObject), so it made sense to tie the (de)serialization behavior to that and register interfaces in deno_core. Nowadays, after https://crrev.com/c/4385565, this is no longer true.

There should still be a single place where the list of serializable interfaces, and their serialization/deserialization functions should be collected – and that maps well to this PR's ext/web/00_interface.js. But rather than just passing those functions to deno_core as it currently does, it's better for 00_interface.js to define generic isSerializable, isTransferable, (de)serialize, transfer/transferRecv functions that work for all interfaces, which then get registered into deno_core and used in the {is,read,write}_host_object methods of the (de)serializer.

There's also the fact that the has_custom_host_object and is_host_object methods have to be added to rusty_v8's definition of v8::ValueSerializerImpl (see https://crrev.com/c/4385565), that the methods in core's Value{De,}serializer trait impl need to have any calls to JS functions wrapped in v8::AllowJavascriptExecutionScope (see denoland/rusty_v8#862), that the core part of this PR needs to be split off into a new PR to denoland/deno_core...

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

Andreu Botella seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}