Bug 116359 – Disable SharedWorker when in multiple web process model

• Component: WebKit2
• Status: RESOLVED FIXED

[Alexey Proskuryakov]

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

<rdar://problem/13819878>

[Alexey Proskuryakov]

Created attachment 202167 [details]
proposed patch

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/r150310>.

[Ryosuke Niwa]

This patch caused a whole bunch of tests to fail on WK2 bots:
http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r150313%20(8978)/results.html

[Alexey Proskuryakov]

Fixed in <http://trac.webkit.org/changeset/150322>.

[Takahiro Ichihashi]

Hello, could you consider/discuss reenabling this feature? 

"The implementation of Shared Web Workers was imposing undesirable constraints on the engine. The feature never gained any adoption and was eventually removed from the engine."
https://webkit.org/status/#feature-shared-web-workers

I understand this, but API itself looks very simple, and easier(-to-use) than service worker.

[Ryosuke Niwa]

(In reply to Takahiro Ichihashi from comment #5)
> Hello, could you consider/discuss reenabling this feature? 
> 
> "The implementation of Shared Web Workers was imposing undesirable
> constraints on the engine. The feature never gained any adoption and was
> eventually removed from the engine."
> https://webkit.org/status/#feature-shared-web-workers
> 
> I understand this, but API itself looks very simple, and easier(-to-use)
> than service worker.

What we need is a compelling evidence that Web developers will use shared workers. Given that people don't even use shared workers in the browsers that support it (Chrome & Firefox), the argument for supporting this feature is rather weak. Also understand that 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.

[Takahiro Ichihashi]

Thanks for your reply.

The reason behind the low adoption rate of the API is probably the immaturity of the developer communities - meaning, it sometimes takes time for new APIs to become mainstream (XHR, formally a vendor-specific Microsoft.XMLHTTP or dynamic <script tag generation technique took 7~8 years to become a core part of web). 

Difficultly I found is that, currently it is a bit tricky to make a script that is shared across windows/tabs; in my case there are persistent connections via websocket / webrtc that provides some information periodically, which I want to make it more efficient by just having a one thread/tab that handles such connection even when there're multiple tabs opening, but at this time a polyfill should be made probably by utilizing localStorage events. 

Service workers will solve this problem (I'm fine with this API given a lower development priority compared to service worker anyway) but personally I feel that service workers have got so many features, and I believe there's a possibility that shared worker would be loved by many developers with specific needs like the above one. But thanks for your quick reply anyway, pls let me know if anything that I can help.

Hi,

I work at Chess.com. We're definitely interested in SharedWorkers, but since it's not supported in all browsers and there are no polyfills, we can't use them. So, low adoption rate is inevitable. It'd be nice if you'd reconsider.

[Igor Zvyagintsev]

(In reply to Ryosuke Niwa from comment #6)
> What we need is a compelling evidence that Web developers will use shared
> workers.

Naturally, developers don't use SharedWorkers because it isn't supports in all browsers and no way to polyfill it.

[Ryosuke Niwa]

(In reply to nmrugg from comment #8)
> I work at Chess.com. We're definitely interested in SharedWorkers, but since
> it's not supported in all browsers and there are no polyfills, we can't use
> them. So, low adoption rate is inevitable. It'd be nice if you'd reconsider.

(In reply to Igor Zvyagintsev from comment #9)
> Naturally, developers don't use SharedWorkers because it isn't supports in
> all browsers and no way to polyfill it.

What are your concrete use cases? Wanting to share scripts across tabs/pages isn't one. That's a very specific mechanism by which some use case is addressed. Sharing a network connection between multiple tabs is one abstract use case that came up but that's better served by a service worker.

[Igor Zvyagintsev]

(In reply to Ryosuke Niwa from comment #10) 
> What are your concrete use cases?

Synchronous logout e.g. when the user presses the exit button, he must automatically log out of the system and on the other tabs. It's real task assumed on me in Jira.

[Kellen Green]

At the moment I'm using SharedWorkers to Share a single WebSocket connection between all tabs. 

ServiceWorkers (from my understanding) would not be sufficient for such a use case.

(In reply to Ryosuke Niwa from comment #10)
> What are your concrete use cases? Wanting to share scripts across tabs/pages
> isn't one. That's a very specific mechanism by which some use case is
> addressed. Sharing a network connection between multiple tabs is one
> abstract use case that came up but that's better served by a service worker.

At Chess.com, we are considering running a single instance of a WASM chess engine that can be shared across multiple tabs. The chess engine takes a lot of resources and also has a noticeable start up time. Sharing one could be useful for certain tasks.