Implement SharedWorker

[jdm]

https://html.spec.whatwg.org/multipage/workers.html#shared-workers-introduction

https://html.spec.whatwg.org/multipage/workers.html#shared-workers-and-the-sharedworkerglobalscope-interface
https://html.spec.whatwg.org/multipage/workers.html#shared-workers-and-the-sharedworker-interface

Depends on #7457.

[Ms2ger]

I believe just Gecko implements this now, so it's not entirely clear this is going to stay in the platform.

[jdm]

http://caniuse.com/#feat=sharedworkers says Chrome does too.

[tetsuharuohzeki]

In my feeling as a client-side web content developer, SharedWorker is ignored in web development scene now. I don't know why its feature is ignored, I suspect these things Firefox have implemented it in v29 and Safari drops it from v6.

I agree @Ms2ger 's thought. We can wait the result of Firefox's telemetry about SharedWorker https://bugzilla.mozilla.org/show_bug.cgi?id=1193414 .

[jdm]

That being said, ServiceWorkers would use a lot of the same infrastructure as SharedWorker, so this could still be valuable.

[NekR]

Sometime ago I heard that SharedWorkers are deprecated. Right ServiceWorker spec team considers using SharedWorkers inside ServiceWorker for heavy tasks / shared memory.

So you may still need SharedWorkers again some day.

[avinash-vijayaraghavan]

@jdm
this looks interesting. would like to try it out if it is a mentored project

[jdm]

@avinash-vijayaraghavan There's no clear benefit to working on it at this point in time, so I don't think anyone will want to put in the time to mentor it.

[gterzian]

Couple of design ideas, based on current ongoing work at #23637:

1. Constellation owns a HashMap<(Origin, Url), SharedWorker>(or just origin -> worker) .
2. A SharedWorker is similar to an EventLoop, essentially a wrapper around an IPC sender and a pipeline Id(or a SharedWorker is a process that runs one worker-event-loop per Url in threads).
3. The differencen is that a SharedWorker runs a(or several) worker event-loop(s), not a ScriptThread. A "worker event-loop" is essentially the run_worker_scope method of DedicatedWorkerScope, give or take.
4. So when script does new SharedWorker(scriptURL [, name ]), it:
   • Creates two message ports and entangles them.
   • Stores one onto the local global and a SharedWorker dom object.
   • Transfers the other, and sends it to the constellation in a message along with relevant info.
5. The constellation, upon receiving such a message:
   • Either creates a new worker or reuses an existing one.
   • In both cases, it ends up forwarding the message containing the port to the worker.
6. The SharedWorkerScope then runs some glue code to handle the new port, fire the connect event, and then essentially does a self.upcast::<GlobalScope>.track_message_port(port).

So hopefully a SharedWorkerScope can be basically a copy/paste from DedicatedWorkerScope, with some additional glue to handle new incoming ports, which really should just call into the methods of GlobalScope that handle message-ports in any other scope.

At that point there is a direct IPC communication line, in the form of the port, between a script-process, and a shared-worker process, while the constellation keeps ipc-senders to both, and both also have an ipc-sender to the constellation.

---

Note that this "storing the worker on the constellation and running it in it's own process, while making it available to any same-origin script", could be a way to re-structure service workers too.

---

So, reading up on this issue, I'm not sure if it's a very high-value project in itself, however I do think testing the design I sketch above could be a valuable lesson to potentially refactor service-workers(see #19302).

Also, the hard parts are MessagePort and "running a worker"(basically dedicated worker but out-of-process from script and with some coordination from the constellation).

So once we have message-ports, it's basically re-using those as well as dedicated worker, with a bit of additional constellation glue. I don't see this being a very large project in and of itself.

And, it's not like it up for deprecation or anything(?), so with message-ports and dedicated worker in place, it'd be a pity not to go ahead and finish this one too.

[gterzian]

One more thing: Service and Shared workers also differ in that Service workers are meant as stateless, event-driven, never-block kind of components that potentially run independently of any web page, whereas Shared workers are really meant to share state(and centralize running some logic to produce that state) between different pages running the same origin.

I think it's worth it to implement Shared workers, since 2015 there has been quite a lot of progress on the compatibility side: https://developer.mozilla.org/en-US/docs/Web/API/SharedWorker#Browser_compatibility

It looks like only Safari and Android Webview do not implement it.

[CYBAI]

It looks like only Safari and Android Webview do not implement it.

About WebKit, they implemented it but removed it.
https://webkit.org/status/#feature-shared-web-workers

Not read yet but maybe related WebKit issues:
https://bugs.webkit.org/show_bug.cgi?id=116359
https://bugs.webkit.org/show_bug.cgi?id=140344

[gterzian]

Thanks for sharing those issues. https://bugs.webkit.org/show_bug.cgi?id=116359 is particularly interesting. It actually seems that there are people complaining about not having this feature being consistently implemented across browsers.

Shared workers can not communicate across processes currently, so they should better be disabled.

That seems to have been the origin reason for the removal.

the engineering resources spent to make shared worker work is the engineering resource that can't be spent elsewhere like implementing service workers so there is a huge opportunity cost associated with making this feature work across web content processes.

And this is an argument I disagree with, since shared-workers are basically re-using dedicated workers but with additional infra, and that additional infra is the same stuff that service workers would be using(minus the message port).

What makes service workers a lot of extra work is orthogonal to shared-workers, and they could otherwise share a common infrastructure.

[gterzian]

Also, I think this would fit very well in the overall design of Servo, hence shouldn't be exactly very hard or a lot of resources redirected from other things.

And having a worker run in a separate process from script, using a message-port as the communication channel between that worker and multiple potential script-process clients, is generally a problem that if solved once could open up other opportunities, such a discussed in #23807 (and on how to do Service workers as well).

Currently our only implementation of workers(dedicated workers) consists of running a thread right inside a script-process. So we haven't tried anything related to running a worker in a separate process, separating the life-cycle of a worker from that of a given script-thread(process).

It would be much easier try this with SharedWorker first, since you can re-use alsmost the entire "run a worker" logic from dedicated workers, than trying to do this first with Service worker or worklets.

Hence I see this mainly as a good first pass at introducing a new kind of component in Servo, the out-of-process worker, which could then be generally re-used in other more complicated workers.