Re: [w3ctag/design-reviews] Extended lifetime shared workers (Issue #1089)

asutherland left a comment (w3ctag/design-reviews#1089)

From an implementation perspective (for Gecko), `runCleanupOnExit` introduces scary new platform responsibilities and complexities that I don't think we want to sign up for, especially since it entails 1-2 orders of magnitude more work than the proposal in https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b.

Specifically:
- runCleanupOnExit implies a browser obligation to reliably run something when a global goes away.  Whereas I view the proposal at https://gist.github.com/domenic/c5bd38339f33b49120ae11b3b4af5b9b as more caving a cowpath for a capability we can't take back and where it's probably better for everyone involved if people aren't using a ServiceWorker in that case.
- The eager delivery of postMessage is straightforward and already implemented.  runCleanupOnExit implies a whole bunch of new edge-cases and implementation complexities unless we explicitly use the existing structured serialization `forStorage` flag and define things in terms of actually being stored and charged against quota.

I do want to emphasize that I appreciate the thought and care that went into the runCleanupOnExit proposal and attempts to address the existing structural problems of SharedWorker.  It would be definitely interesting to revisit the fundamental idea as an entirely new and separate proposal like a `BatchWorker` where the "forStorage" aspects could potentially be advantageous.  But I do want to emphasize that would still be similarly a major implementation undertaking.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1089#issuecomment-3235296356
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1089/3235296356@github.com>