create public interface for WorkerPrivate to hide implementation details, possibly using nsIGlobalObject for on-worker-thread use-cases
Categories
(Core :: DOM: Workers, task, P2)
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.
Updated•7 years ago
|
Comment 1•4 years ago
|
||
:perry, probably we should order our WorkerPrivate enhancements a bit and track them together?
Comment 2•4 years ago
|
||
Yeah, this would be a big quality of life improvement...
Comment 3•4 years ago
•
|
||
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 | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 4•3 years ago
|
||
:ssengupta to take over with Eden uploading current WIP.
Comment 5•3 years ago
|
||
Hi Andrew, please take over that WIP patch for further decisions.
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Updated•2 years ago
|
Updated•1 year ago
|
Comment 6•1 year ago
|
||
(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.)
Description
•