Shared Storage worklet switching to blink WorkletGlobalScope

[Yao Xiao]

Hi platform-architecture-dev@,

For the shared storage worklet, I'm looking into switching to blink WorkletGlobalScope, to take advantage of IDLs, devtools. It looks like the approach would violate the existing laying (i.e. //content/services/shared_storage_worklet will need to depend on (non-public) blink code). But I also don’t see other ways to get the benefit I want without violating the laying.

This is a design doc (shared with "Chromium" group). Glad to hear your thoughts. Thanks!

-------
Yao

[Daniel Cheng]

How about moving the shared storage support code into Blink itself? Maybe this is because the code actually isn't running in the renderer process, but in the utility process? In that case, I think having it live in third_party/blink/renderer/modules would be a bit misleading.

We haven't had a third_party/blink/services or third_party/blink/utility until now, but if this is something that would be useful, I think we could consider it. However, we would need to restructure some of the layers so that things like bindings could be reused across both renderer and utility services though—I'm not sure how much work this would be. There was previously work on this front to factor out parts of the bindings code so that we could reuse it for extensions, but we eventually abandoned that. +jbroman and +adityhas would have more context there.

Finally, there are ways to add glue to the Blink public API to avoid the layering issues described in the document (e.g. a 'holder' Blink public API object that has a WebPrivatePtr to the actual Blink implementation). But we've tried to encourage code to live directly in Blink instead when it makes sense instead of adding temporary API abstractions that someone else will have to try to clean up later.

Daniel

--
You received this message because you are subscribed to the Google Groups "platform-architecture-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to platform-architect...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALYudgUCmSshuBMeoNSG6BJzbX7NnMWTAA7b%2B_t4H4or%2BN%2BTnQ%40mail.gmail.com.

[Daniel Cheng]

(oops actually CCing the people I referenced previously for real)

[Kentaro Hara]

Just to confirm: Shared Storage is not a web-exposed feature, right? Then it should not simply go to Blink -- IDLs in core/ and modules/ are for web-exposed features.

There was previously work on this front to factor out parts of the bindings code so that we could reuse it for extensions, but we eventually abandoned that. +jbroman and +adityhas would have more context there.

We completed the work and we have renderer/extensions/. Currently ChromeOS extensions are the only customer but I think it's reasonable to add Shared Storage.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CAF3XrKoBuFjDhLLtN6COdTn-uDoWg7Z6HHCzAhBq2Vtjrs9btw%40mail.gmail.com.

--

Kentaro Hara, Tokyo

[Yao Xiao]

Just to confirm: Shared Storage is not a web-exposed feature, right?

-- This is not correct. Shared Storage IS a web-exposed feature (explainer)

Yao

[Kentaro Hara]

Then I think it *should* be implemented in renderer/modules/ :D

In the design doc, you are saying:

> The end goal is: instead of hosting the worklet in a renderer (off-main) thread, we want to use a utility process to host the worklet environment. This architecture allows to transite to the utility process architecture with very little friction (% performance overhead of starting up the process).

Why do you need to run the worklet in the utility process? If it's a web-exposed worklet, I think it's more straightforward to follow the architecture of other worklets and run it in a renderer process.

--

Kentaro Hara, Tokyo

[Yao Xiao]

Re: Why do you need to run the worklet in the utility process?
-- The concern is privacy and security: we don’t want the Document / main process to know the information in the worklet.

---------

Yao

[Daniel Cheng]

On Tue, 14 Feb 2023 at 17:52, Yao Xiao <yao...@chromium.org> wrote:

Re: Why do you need to run the worklet in the utility process?
-- The concern is privacy and security: we don’t want the Document / main process to know the information in the worklet.

---------

Yao

Hm, but that means we need to implement a new process allocation policy for these utility process worklets, right?

I think we could find some way to make this isolation strategy work with the normal renderer process allocation strategy. I would talk to the CSA team about that if we decide to pursue this route.

(I think there's also a general perception that Blink renderers are relatively heavyweight and that a utility process is more lightweight; however, I don't know if this statement is still true if we need to initialize Blink anyway)

Daniel

[Dominic Farolino]

How about moving the shared storage support code into Blink itself? Maybe this is because the code actually isn't running in the renderer process, but in the utility process? In that case, I think having it live in third_party/blink/renderer/modules would be a bit misleading.

Currently the shared storage worklets today are running inside Blink, on another thread in the initiator document's process. It's just that the design is flexible enough to allow them to run in a utility process (with some extra effort) but this is not implemented in practice today.

However, we would need to restructure some of the layers so that things like bindings could be reused across both renderer and utility services though—I'm not sure how much work this would be

My 2¢ is that this would be a big project. Today's WebIDL bindings appea, to my untrained eye, to be inextricably connected with Blink internals like ExecutionContext, lifecycle observation, the Blink garbage collector, and so on, and lifting enough of that outside of Blink (as we know it today) so that a utility process could become a WebIDL bindings embedder without being a full Blink embedder strikes me as a lot of work. The benefit would be retaining the ability to allow worklet execution in a utility process instead of e.g., a renderer process separate from the document's initiator. This would be a nice flexibility to support, but it is not currently implemented today so its priority is hard to judge.

Rather, I personally think it would be more desirable to run the worklets in a proper renderer process so that they go through the usual RenderProcessHost process selection code, and use the Blink code as it stands today. Then I guess we could have the following still-flexible configuration:

1. The ability for the worklets to run directly in another thread in the initiator Document's same process
2. Or another renderer process that the RPH selection criteria chooses, with perhaps some additional Shared Storage-specific input

It's true that we'd incur whatever "heaviness" comes with initializing a Blink renderer as opposed to a lighter-weight utility process, but the delta between those two is not really clear to me, especially if we were to try and run more Blink bindings and GC code inside utility processes (dcheng@ mentioned this point above).

[Jeremy Roman]

+1 to using blink infrastructure for this; glad to see this evolving in that direction.

I don't follow the need to expose Blink internals to content/renderer/ to do that. I would expect that we would simply need an entry point to spawn these worklets, much like how we spawn service workers (see SharedWorkerFactory). We can then use whatever process allocation strategy we deem appropriate. Conceptually that seems like the cleanest strategy.

[Yao Xiao]

Hi Jeremy,

I guess directly accessing the blink internals just reduces the number of layering (prototyping code — same "entry point" with the existing/legacy code.)

I see that it can be done indirectly via //content/renderer => //blink/renderer/core/exported => //blink/renderer/core/workers. (Still, does that mean the worklet code needs to be in renderer/core, rather than renderer/modules? I'm seeing that other existing web-platform "worklet" (not "workers") code still lives in /modules)

Anyway, if it’s very critical not to let //content/render accessing //blink/render/module, I can do that (still preferring accessing it directly for the initial iteration of the migration, if allowed).

------

Yao

[Jeremy Roman]

For stuff that doesn't need to integrate with other stuff in content/renderer/ I'd just IPC straight into Blink, which can already process Mojo messages directly from content/browser/.

If it does need to touch content/renderer/, look at e.g., the code for WebEmbeddedWorker for a similar example that crosses the Blink API boundary. It doesn't need to go in core; that exact example calls into modules/exported/.

We've made intentional architecture decisions to separate the types used in third_party/blink/renderer/ and I don't think we should try to hack a third path through the layer boundary here.