Avoid using the thread pool in TabSources

NEW
Unassigned

Status

DevTools
Debugger
3 years ago
6 days ago

People

(Reporter: jlongster, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
Once bug 1137384 lands, we will have a TabSources object instead of ThreadSources, which is available on the tab actor instead of the thread. When TabSources creates a SourceActor, it adds it to `this._thread.threadLifetimePool`, which is what it did previously.

We should think if this still makes sense. fitzgen mentioned using the tab actor pool instead so non-ThreadActor actors don't have to worry about lifetimes. Sources should only exist for the extent of the thread, however. When we reload the tab, all sources should be cleared.

I'm not too familiar with lifetimes so I don't know if this should be changed or not. I'd like to hear about a non-ThreadActor use case where moving to the tab actor pool would help.
We should create a navigationLifetimePool on the TabActor for things that should be explicitly navigation lifetime.
I've been thinking about this lately, and I think we should reconsider the introduction of TabSources. The main reason is that each worker also has a ThreadActor, and these ThreadActors cannot access the TabSources object in the main thread. The second reason is that we're trying to pretend that sources have navigation lifetime, but that's simply not accurate: sources have thread lifetime. If a worker goes away, the sources for that thread go away, even if we didn't navigate away from the page. In fact, we still use thread lifetimes for the source actors right now, so apparently TabSources cannot even be safely used unless you've attached to the thread.

Obviously, we still need a way for other tools to access sources, but I'd like us to discuss alternatives to the current implementation.

Updated

6 days ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.