I wanted to add one concrete use case where shared -> dedicated nesting would eliminate the need for implementing coordination, proxying, and leader-election logic across tabs via BroadcastChannel, Web Locks, heartbeats, or similar mechanisms — WASM SQLite.
A SharedWorker is the natural cross-tab coordination point. The shared worker could handle proxying query requests from tabs, caching, etc. While the dedicated Worker manages the SQLite runtime, storage access, and querying against the db. SQLite in a dedicated worker is important because SQLite WASM needs OPFS sync access handles via createSyncAccessHandle() for meaningful performance gains. Today this is how this is solved: - In wa-sqlite, they describe 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 and https://github.com/rhashimoto/wa-sqlite/blob/master/demo/SharedService/SharedService.js - 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 leverage WASM SQLite end up implementing these 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/c3e80de2-e6d9-4be8-9819-10bd3ec280a9n%40chromium.org.
