- From: Marijn Kruisselbrink <notifications@github.com>
- Date: Tue, 14 Nov 2017 20:53:52 +0000 (UTC)
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1224@github.com>
I might be missing something here, but the Run Job algorithm currently just says "Queue a task to run [this job]", and I don't understand what it means to "queue a task" on a unspecified event loop. The definition of "queue a task" just mentions "the relevant event loop", but I'm not sure what that means in the context of the "Run Job" algorithm. When "Run Job" is invoked by "Schedule Job" I suppose it could arguably be the event loop of the document that called register or update (but does that mean that if the document goes away before the task runs, registration should be aborted?), and similarly when invoked by "Finish Job" it could arguably be the event loop the task for the just finshed job was running on, but that still has the same problem with what happens if that event loop goes away (or maybe it is still supposed to be the task queue/event loop of whoever originally scheduled the job?). Is there supposed to be some separate SW processing event loop or something these tasks are supposed to run on? It doesn't seem like posting tasks to event loops associated with arbitrary (or even non-arbitrary) documents and/or workers could ever work, as that would mean the registration wouldn't complete if the document goes away before registration finishes (well, if registration didn't start before the event loop went away, which I guess might be okay?) Either way it seems we should clarify what the relevant event loop is for "Run Job" -- 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/issues/1224
Received on Tuesday, 14 November 2017 20:54:16 UTC