Open Bug 1350337 Opened 6 years ago Updated 2 months ago

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

Categories

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

task

Tracking

()

People

(Reporter: bkelly, Assigned: edenchuang)

References

(Blocks 1 open bug)

Details

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.

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

Flags: needinfo?(perry)
See Also: → 1539508

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

Flags: needinfo?(perry)

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.

Assignee: nobody → echuang
Blocks: 1539508
See Also: 1539508
Type: enhancement → task

:ssengupta to take over with Eden uploading current WIP.

Assignee: echuang → ssengupta
Flags: needinfo?(echuang)
Summary: create public interface for WorkerPrivate to hide implementation details → create public interface for WorkerPrivate to hide implementation details, possibly using nsIGlobalObject

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

Assignee: ssengupta → bugmail
Assignee: bugmail → echuang
Flags: needinfo?(echuang)
Priority: P3 → P2
Severity: normal → S3

(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.)

Summary: create public interface for WorkerPrivate to hide implementation details, possibly using nsIGlobalObject → create public interface for WorkerPrivate to hide implementation details, possibly using nsIGlobalObject for on-worker-thread use-cases
You need to log in before you can comment on or make changes to this bug.