Run Job does not specify which event loop to queue its tasks on

[mkruisselbrink]

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"

[wanderview]

I feel like the spec should require that there be a single event loop in the browser for running jobs so that we can guarantee state is coherent. It doesn't matter which event loop that is, though. It could be a completely separate thread from anything else. We've certainly talked about moving service worker job stuff off main thread and it would be nice to maintain that option.

[mkruisselbrink]

Yeah, that makes sense to me. Would require updating the HTML spec to define a third type of event loop (since currently it explicitly says browsing context event loops and worker event loops are the only types of event loops), but presumably that shouldn't be a problem.

[jungkees]

Yes, we need a separate thread from the main thread (as implementations have such as a thread in a browser process, storage process, etc.). I'm thinking of using https://html.spec.whatwg.org/#parallel-queue to serialize Run Jobs. (The parallel queue has recently been added to HTML to cover this kind of requirement.)

That considered, does it make sense to create a parallel queue for this jobs when user agents boot up?

[gterzian]

What is the current status of #1229 ?

The Run Job algorithm also confused me (today) with it's use of task queuing, followed by immediately running the actual job "in parallel".

I agree the parallel queue appears like the right primitive to express what a "job queue" is. There are parallels(no pun intended) with the shared-worker-manager used in the HTML spec(which have been noted in the PR already I see).

Reading up on the comments above, I think the use of a parallel queue already implies a kind of "event-loop" running those steps serially, hence there would be no need to define a new type of event-loop(the open PR doesn't seem to attempt doing that either), especially since the event-loop in the HTML spec is usually about running an agent, while this parallel queue is about running steps in parallel to an agent. So the parallel queue I think is really an "event-loop light" that can be used to express what in practice will be some IPC based message pump that does not directly tie into running an agent.

Finally, perhaps we could also get rid of the scope-to-job-queue-map? It would seem like scoping the job queue per scope-url would not offer material benefit at the spec level, just like scoping it per origin doesn't, as a un-scoped wording still leaves the possibility for the UA to run multiple job queues in parallel per origin or even scope, I think(the parallelism would not be observable).