Re: [ServiceWorker] Event queuing model for SW (#649)

> Do you mean "abort the substeps" above?

Yes abort the rest of the steps in Run Service Worker. The steps in the above comment is just a snippet I put together to show the idea.

> Losing events seems really bad. We should not let that happen. 

Agreed on having to not let the events lost before getting dispatched. Curious to know whether the points you concern the events can be lost are before being dispatched or after queued in the service worker (in which case you might have meant lost by termination)?

> One way could be to only handle new external tasks once the existing tasks have finished or resulted in service worker termination.

By "the existing tasks" here, do you mean the tasks already queued in the service worker's responsible event loop's task queue? If so, what's the model in your mind that'd delay handling those new external tasks? Is that an external queue or trying to delay queuing a task somehow?

> If someone creates a bunch of tasks in a running service worker that should not then lead to the next hundred network fetches getting lost if the UA decides upon termination.

UA terminating a service worker seems it implies it's done with the tasks in the queue or met an abnormal operation. Should we really retain and requeue those bunch of tasks which may delay handling the new requests? Also backing up the dropped tasks by putting'em into the external queues again will get the order of the tasks tangled up.

On second thought, I'm open to the external queue idea if needed. An external queue associated with a service worker which persists the lifetime of it seems reasonable. But I'm not sure about whether we should requeue the dropped tasks when UA terminates the service worker. And also I'd like to mull over with all the possible models before coming to a conclusion.

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