I wanted to add one concrete use case where shared -> dedicated nesting would materially simplify real applications.
SQLite WASM implementations are a good example. A SharedWorker is the natural cross-tab coordination point: it can accept connections from multiple tabs, route requests, and handle ownership or leader-election logic. But the actual database engine often wants to live in a dedicated worker. That is not just a separation-of-concerns preference. Dedicated workers also expose capabilities that shared workers do not, including OPFS sync access handles via createSyncAccessHandle(), which are only available in dedicated web workers. In practice, that makes this a very natural architecture: - SharedWorker for cross-tab coordination and request routing - dedicated Worker for the SQLite runtime and storage access Without SharedWorker -> Worker, libraries end up having to contort their design and are reimplementing coordination, proxying, and leader-election logic across tabs using BroadcastChannel, Web Locks, heartbeats, or similar mechanisms. This is especially painful for multi-tab database access, where one context needs to own the database and other tabs need to proxy requests to it. So from the perspective of SQLite WASM and similar runtimes, support for shared -> dedicated is not just a convenience. It would remove real complexity and enable cleaner, more robust multi-tab designs. References in the popular client-side SQLite libraries: - In wa-sqlite, Roy Hashimoto describes a multi-tab setup where one tab becomes the service provider, another tab takes over if it closes, a small SharedWorker passes MessagePorts, Web Locks track tab lifetime, and BroadcastChannel coordinates migration: https://github.com/rhashimoto/wa-sqlite/discussions/81 - A follow-up wa-sqlite discussion applies that pattern to an OPFS-backed shared database service across multiple tabs: https://github.com/rhashimoto/wa-sqlite/discussions/84 - In the official SQLite WASM docs, the opfs-sahpool concurrency section explicitly points to those wa-sqlite discussions for client-level solutions, because the library itself cannot transparently solve this at the VFS level. It instead exposes cooperative handoff primitives such as pausing the VFS so another tab/worker can take over: https://sqlite.org/wasm/doc/tip/persistence.md#sahpool-concurrency Applications like Notion and frameworks like TanStack DB which rely on WASM SQLite end up implementing these more complex coordination patterns to enable functionality and performance in multi-tab environments. Additional references: - https://tanstack.com/blog/tanstack-db-0.6-app-ready-with-persistence-and-includes - https://www.notion.com/blog/how-we-sped-up-notion-in-the-browser-with-wasm-sqlite On Wednesday, July 18, 2018 at 2:00:49 PM UTC-4 Nate Chapin wrote: > Update: concerns came up during code review > <https://chromium-review.googlesource.com/c/chromium/src/+/953746> that > allowing the creation of dedicated workers from a shared worker would lead > to dependencies on deprecated code that would be difficult to untangle, so > for the initial commit we are only going to support nesting > dedicated->dedicated. I hope to add shared->dedicated nesting soon. > > On Mon, Jun 4, 2018 at 11:33 AM, Nate Chapin <[email protected]> wrote: > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *Contact [email protected] to nested workers are >> spread through section 10 of the HTML spec. For example, >> https://html.spec.whatwg.org/#the-worker's-workers >> <https://html.spec.whatwg.org/#the-worker's-workers>SummaryWorkers should >> be able to spawn additional, descendant dedicated workers.This exposes the >> dedicated worker constructor to shared workers and dedicated workers. >> While there has been discussion <https://github.com/whatwg/html/issues/411> >> about allowing service workers to create dedicated workers, there is no >> spec support at this time. Note that the spec states that we should also be >> able to create shared workers from a dedicated worker or shared worker, but >> that is substantially more complex to implement, so there is no immediate >> plan to support it.MotivationSpec support for nested workers is old, and >> lack of nested worker support is one of our more glaring divergences from >> the spec. https://bugs.chromium.org/p/chromium/issues/detail?id=31666 >> <https://bugs.chromium.org/p/chromium/issues/detail?id=31666>, which >> requests this feature, is one of the most starred Blink issues in the bug >> tracker.Nested workers would allow libraries which use workers to be >> adapted to run in a worker context themselves, giving developers more >> options to move business logic off of the main thread.RisksInteroperability >> and CompatibilityEdge: ShippedFirefox: ShippedSafari: There's an open >> WebKit issue, but no recent activity: >> https://bugs.webkit.org/show_bug.cgi?id=22723 >> <https://bugs.webkit.org/show_bug.cgi?id=22723>Web developers: In favor, if >> https://bugs.chromium.org/p/chromium/issues/detail?id=31666 >> <https://bugs.chromium.org/p/chromium/issues/detail?id=31666> is any >> indication. It’s the 11th most starred component:Blink bug >> <https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component:Blink&sort=-stars&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified> >> >> in the chromium tracker.ErgonomicsIt's unclear to me how much effort should >> be put in to preventing developers from shooting themselves in the foot >> with workers (e.g., by preventing infinite recursion or putting a limit on >> the total number of workers that can be active at a given time). There >> isn't anything specific in the spec at the moment, but I'm open to >> suggestions.ActivationUsing nested dedicated workers should be no more >> difficult than using normal dedicated workers. This change would make it >> possible to use libraries from a worker that themselves create worker, >> which makes adopting workers more viable for library authors.There may be >> additional work to do regarding memory consumption and preventing >> developers from exhausting memory if it becomes apparent that there are >> strong use cases for having many nested workers.DebuggabilityNested workers >> should be visible in developer tools, just like any other worker. There is, >> however, no indication that they are nested or which other worker owns the >> nested worker. I've filed >> https://bugs.chromium.org/p/chromium/issues/detail?id=848450 >> <https://bugs.chromium.org/p/chromium/issues/detail?id=848450> to follow up >> on that.Will this feature be supported on all six Blink platforms (Windows, >> Mac, Linux, Chrome OS, Android, and Android WebView)?Yes.Is this feature >> fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>?* >> >> external/wpt/workers/nested_worker.worker.js exercises basic >> functionality.* >> html/infrastructure/safe-passing-of-structured-data/shared-array-buffers/ >> tests shared array buffers in nested worker contexts.* >> external/wpt/secure-contexts/ exercises their security properties.* >> external/wpt/websockets/Create-on-worker-shutdown.any.js tests websocket >> creation in nested workers.My draft CL >> <https://chromium-review.googlesource.com/c/chromium/src/+/953746> also >> adds tests to verify sync XHR and importScripts() in nested workers, and >> modifies an existing worker modules test to test the ability to load >> modules into nested workers.Link to entry on the feature >> dashboardhttps://www.chromestatus.com/feature/6080438103703552 >> <https://www.chromestatus.com/feature/6080438103703552>Requesting approval >> to ship?Yes.* >> >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ca4998f4-fd2c-4a13-b50c-b441572e32e6n%40chromium.org.
