Re: [ServiceWorker] unregister() then register() same-scope, different script URL that fails: what do you expect to happen? (#396)

About comment https://github.com/slightlyoff/ServiceWorker/issues/396#issuecomment-73318943
It has to do with queuing. The timing exception is more of a sort-a-kinda fix to this, since it is impossible for a browser to determine if the worker is stuck, or being evil, or really doing something important, when deciding to time it out.

For installation, we have a install queue, and install result queue. What this allows is the splitting up of the install algorithm, gating the "set of steps before "install" event is sent to worker" on install queue and then "set of steps after "install" event is set to worker" on install result queue. What this means is that even if workerA is waiting for a long time in the install event, other workers for the same scope can continue to reach the install state (where they are sent the install event), before getting blocked.
On the other hand, since Activate is called from inside a set of atomic steps, instead of being called non-atomically and then having its own activation result queue, it means that no other workers get sent the activate event if a worker is currently handling the event. I was wondering if it could follow the installation pattern for consistency. I don't think it matters a lot :)

---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/396#issuecomment-73805126