Re: representing execution context on the browser side

[Daniel Cheng]

On Tue, 22 Oct 2024 at 02:47, Fergal Daly <fer...@google.com> wrote:

Recently we have been talking about mojo pipes that should have lifetimes that correspond to the ExecutionContext that created them. Implementing that has been quite awkward. It feels to me that there is a missing piece in our browser-side infrastructure.

I wrote a doc about it with a proposal for one way to address this,

F

[Dave Tapuska]

There are execution contexts that aren't represented at the browser side at all like worklets. 

--
You received this message because you are subscribed to the Google Groups "content-owners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owner...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CAF3XrKqsRAM%3DsCTV%3DAHf6P5kgdX_j%2BZULw%3DuJMc%2BZr5JbvpbfQ%40mail.gmail.com.

[Fergal Daly]

On Wed, 23 Oct 2024 at 03:11, Dave Tapuska <dtap...@chromium.org> wrote:

There are execution contexts that aren't represented at the browser side at all like worklets. 

The problem I'm trying to solve is that writing code in the browser to work with the existing execution contexts generically is a pain. I don't think anything I'm proposing would be incompatible with representing worklets or other ECs in the browser in the future if someone needs that,

F

[Chris Hamilton]

Lurker drive-by: the performance_manager component does tracking at the level of ExecutionContexts (both workers and frames). If the code you're adding is at the chrome layer (and not content) you could potentially use that? If you do need it at the content layer, and this plan moves forward, then performance_manager code could be simplified. FYI: +Joe Mason 

Cheers,

Chris

You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAAozHLnR1DYZ-ZXkNWryoLt1-9mHLayHEi3bMnrF5vR3WJViQA%40mail.gmail.com.

[Charlie Reis]

Thanks, just seeing this now.  Having a representation for ExecutionContextHost in //content seems like it could be useful, both for scoping the lifetime of objects as you mention, and for tracking common state in the browser.  In theory, I think all of the types of execution contexts have SiteInstances associated with them, so maybe it could be a common place for each of them to track their SiteInstance?  Specifically:

• RenderFrameHost has a SiteInstance
• ServiceWorkerHost has an associated SiteInstance in ServiceWorkerProcessManager here, IIUC
• SharedWorkerHost has a SiteInstance
• DedicatedWorkerHost has a DedicatedWorkerCreator, which I think itself is an execution context (either an RFH or a worker)

I'm not sure how easy that is at the code level, but conceptually it makes sense to me at a high level.

Charlie

On Thu, Oct 24, 2024 at 7:28 AM 'Fergal Daly' via content-owners <content...@chromium.org> wrote:

On Wed, 23 Oct 2024 at 22:48, Chris Hamilton <chr...@google.com> wrote:

Lurker drive-by: the performance_manager component does tracking at the level of ExecutionContexts (both workers and frames). If the code you're adding is at the chrome layer (and not content) you could potentially use that? If you do need it at the content layer, and this plan moves forward, then performance_manager code could be simplified. FYI: +Joe Mason 

Thanks.

Unless someone has an objection, I will prototype something and get back here with a CL,

F

Cheers,

Chris

On Tue, Oct 22, 2024 at 7:57 PM 'Fergal Daly' via navigation-dev <navigat...@chromium.org> wrote:

On Wed, 23 Oct 2024 at 03:11, Dave Tapuska <dtap...@chromium.org> wrote:

There are execution contexts that aren't represented at the browser side at all like worklets. 

The problem I'm trying to solve is that writing code in the browser to work with the existing execution contexts generically is a pain. I don't think anything I'm proposing would be incompatible with representing worklets or other ECs in the browser in the future if someone needs that,

F

 

On Tue, Oct 22, 2024 at 1:09 PM Daniel Cheng <dch...@chromium.org> wrote:

On Tue, 22 Oct 2024 at 02:47, Fergal Daly <fer...@google.com> wrote:

Recently we have been talking about mojo pipes that should have lifetimes that correspond to the ExecutionContext that created them. Implementing that has been quite awkward. It feels to me that there is a missing piece in our browser-side infrastructure.

I wrote a doc about it with a proposal for one way to address this,

F

--
You received this message because you are subscribed to the Google Groups "content-owners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owner...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CAF3XrKqsRAM%3DsCTV%3DAHf6P5kgdX_j%2BZULw%3DuJMc%2BZr5JbvpbfQ%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "navigation-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to navigation-de...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/navigation-dev/CAAozHLnR1DYZ-ZXkNWryoLt1-9mHLayHEi3bMnrF5vR3WJViQA%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "content-owners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owner...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CAAozHLmA6txSWmQUO%2BjYL9aUd6srL-AfB2ZZmNf5kKtsHX0Tuw%40mail.gmail.com.

[Fergal Daly]

On Wed, 23 Oct 2024 at 22:48, Chris Hamilton <chr...@google.com> wrote:

Lurker drive-by: the performance_manager component does tracking at the level of ExecutionContexts (both workers and frames). If the code you're adding is at the chrome layer (and not content) you could potentially use that? If you do need it at the content layer, and this plan moves forward, then performance_manager code could be simplified. FYI: +Joe Mason 

Thanks.

Unless someone has an objection, I will prototype something and get back here with a CL,

F

Cheers,

Chris

[Joe Mason]

A content level ExecutionContext class should be pretty trivial to write. We could convert the PM ExecutionContext, or deprecate it in favour of the content/ one, or just keep two parallel impls for a while.

For background, Performance Manager already has some classes that correspond to Frames (FrameNode <-> RenderFrameHost) and Workers (WorkerNode <-> *WorkerHost, representing any type of worker), whose purpose is two-fold:

1. Provide a bit more simplified / uniform interface than RenderFrameHost / ServiceWorkerHost / etc.

2. Originally PM ran on a separate sequence, because we thought that running algorithms over collections of nodes might block the main thread., which meant we needed "proxy classes" for RFH etc. that lived on the main thread. (We've since decided that the overhead of posting data back and forth between main thread and PM sequence is worse, so we're in the middle of moving PM to the main thread, but until that's done and cleaned up the proxy classes are still needed.)

So ExecutionContext is just a class holding a FrameNode or WorkerNode pointer. It's implemented as an abstract class with a few methods returning data common to frames and workers: blink::ExecutionContextToken (basically variant<FrameToken, DedicatedWorkerToken, SharedWorkerToken, ServiceWorkerToken>), URL, process the frame/worker is running in, and process priority. Origin and SiteInstance would be good additions to that list.

It has 2 subclasses, FrameExecutionContext and WorkerExecutionContext, implementing the functions by forwarding to a wrapped FrameNode or WorkerNode.

That design would be easy to copy over to content/ (with 4 subclasses wrapping RenderFrameHost, DedicatedWorkerHost, SharedWorkerHost, ServiceWorkerHost), or it could just be a concrete class with a variant<RenderFrameHost*, DedicatedWorkerHost*, ...>.

PM's ExecutionContext has a registry so that a single wrapping ExecutionContext object exists for a FrameNode. Another approach would be to give ExecutionContext comparators that compare equal iff the wrapped frames / workers are equal, so that calling `ExecutionContext::From(frame)` multiple times creates multiple thin wrapper objects that are logically equal.

[Fergal Daly]

For the record, the problem I was trying to solve turned out to be solvable without introducing this new concept. So my immediate need for doing this is gone.

I think we could remove a lot of repetition from browser_interface_binders.cc which currently has 4x{everything that binds to a RFH/ServiceWH/DWH/SharedWH} with an ExecutionContextHost (there are problems with that name but it's fine for now). It's not a huge source of pain but it would be a satisfying cleanup,

F