Re: [w3c/ServiceWorker] Experimenting with abortable algorithms (#1443)

@jakearchibald would it be fair to say that the differentiating scenario for abort step usage is when you have really big blocks of steps with lots of shared state mutation? The service worker spec has several big algorithms, but the aborts don't feel too unwieldy simply because there's not a lot of shared state to rollback. But I can totally see this being really nice if there was a lot of shared state that had to be reset.

Assuming the main use of abort steps is shared state reset, I'm not sure that abort steps are actually directly useful for https://github.com/w3c/ServiceWorker/pull/1440, since I would prefer the last resort killswitch algorithm itself to nuke a top level container for all service worker global state, rather than relying on each running algorithm. Pulling the ripcord on a state container seems easier to reason about and verify the guarantees of the last resort killswitch, though I'm not sure if that's feasible.

I can also see abort steps being nice for making the abort return values clear, but similarly, I'd rather keep things simple for https://github.com/w3c/ServiceWorker/pull/1440 and just return null or some other directive indicating that the algorithm has "hard killed" and let the user agent deal with it.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/pull/1443#issuecomment-505668551