Re: [ServiceWorker] Install algorithm step 14 should clear waiting worker before updating state to redundant (#851)

> Well, let me clarify it further as I think it can be a bit misleading. So, here's an example:
If (1) a page has ServiceWorker object 1, (2) a worker has ServiceWorker object 2, and (3) a serviceworker has ServiceWorker object 3 to the same service worker gotten from the getters, Update State will queue a task to (1)'s event loop, (2)'s event loop, and (3)'s loop separately.

Sure, but consider what `registration.installing`, `.waiting`, and `.active` will say in those 3 different event handlers.

On the main thread we are guaranteed that the registration attributes will not change while the event is being handled.  In addition, we can accurately predict the state of the registration attributes by examining when tasks are queued.

Event loops running on separate threads, though, may handle the event simultaneous with the main thread changing the registration attributes.  In addition, its extremely racy as to what state the registration attributes will be in when the event handler is fired.

Another way to handle this would be to be explicit about how we reflect registration attributes into the worker event loop context.  The current spec says they are directly read which implies shared state across threads.  Instead, the spec could indicate the worker DOM objects get tasks queued to update the worker thread exposed attribute.  Then we could reason about how these attributes change consistently with when the state change events fire.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/851#issuecomment-200121674