1350337 - create public interface for WorkerPrivate to hide implementation details, possibly using nsIGlobalObject for on-worker-thread use-cases

Status: NEW

(Core :: DOM: Workers, task, P2)

Description

[Ben Kelly [:bkelly, not reviewing]]

Currently if someone needs to work with Workers at all they probably will end up referencing a WorkerPrivate.  This is a major build headache because it means all the details of the WorkerPrivate are essentially leaked to those consumer.

For example, I want to add an ipdlh defined type to WorkerLoadInfo.  If I do that, though, every directory that includes WorkerPrivate.h must change its moz.build to include:

  include('/ipc/chromium/chromium-config.mozbuild')

In general exposing our concrete type to all consumers makes developing Worker code harder.  There is more busy work for cases like I describe above.  It also makes builds longer by triggering rebuilds of code that don't care about private details of the worker internals.

We really need an abstract WorkerPrivate interface similar to nsGlobalWindow's nsPIDOMWindowInner.

Comment 1

[Jens Stutte [:jstutte]]

:perry, probably we should order our WorkerPrivate enhancements a bit and track them together?

Comment 2

[Perry Jiang [:perry] [no longer employee, use ni?]]

Yeah, this would be a big quality of life improvement...

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

At the all-hands :baku proposed making nsIGlobalObject the public interface, with the intent to move even worker-specific things to this interface like Terminate(). That seems like an excellent plan to me.

edit, much later: nsIGlobalObject is not something we can safely use on the parent thread (or other threads), so although nsIGlobalObject is an appropriate interface for logic on the worker thread, it's definitely the case that there are other use-cases where this is not appropriate. Like the Worker binding held by the parent could not/must not use nsIGlobalObject. There is also the RuntimeService set of use-cases that ideally would be a separate interface because of our plans for the new IPDL protocols for things like sending debugger control messages via IPC rather than via direct runnables.

Comment 4

[Andrew Sutherland [:asuth] (he/him)]

:ssengupta to take over with Eden uploading current WIP.

Comment 5

[Jens Stutte [:jstutte]]

Hi Andrew, please take over that WIP patch for further decisions.

Comment 6

[Andrew Sutherland [:asuth] (he/him)]

(I updated comment 3 with an explicit edit as it relates to nsIGlobalObject and am updating the subject to better reflect that nsIGlobalObject is not suitable or safe to use off the main thread.)