Add support for Web Workers

[joone]

I propose extending the TaskAttributionTiming interface to support Web Workers. This extension would provide details about long tasks and their associated Web Workers.

• Explainer
• Slides
• Chromium issue

[noamr]

As I said at the WG, I'm not sure longtasks are the right abstraction for this use case.
Breaking long tasks into shorter ones matters when there is some sort of prioritization or special-purpose scheduling, such as input and rendering on the main thread. However, workers are general-purpose, and so running 15 * 10ms tasks is the same as running a single 150ms task, as both would equally block the thread.

Perhaps what is needed here is a more ergonomic way to report about work times to the worker's client, e.g. start and end time of processing a postMessage? In that scenario, what happens to tasks that are not a result of postMessage, e.g.

onmessage = event => { 
  fetch(event.data)
     .then(() => {
       // This executes in a new task, not created by `postMessage`
     }); 
}

Alternatively, perhaps some use cases for workers could benefit from a higher level scheduling API, that would make them more "special purpose" and thus benefit from prioritization and breaking tasks. One precedent for this is offscreen canvas and calling requestAnimationFrame inside workers, which can benefit from prioritization and LoAF today.

[joone]

I'm working on another explainer to monitor end-to-end handling of postMessage. At least, we need to support the Long Tasks API in Web Workers because there are cases where workers handle offscreen canvas for games. These scenarios are highly latency sensitive. Also, no matter how long tasks can run in Web Workers, there will always be application-defined limits on acceptable execution times. Therefore, there should be an easy way to identify long tasks running on web workers. In this case, long tasks can be defined differently depending on the context, so the durationThreshold property should be also available in the Long Tasks API(issue).

[noamr]

@joone for the canvas case, we should definitely use LoAF and not longtasks.
The issue with durationThreshold is that it can't work together with buffered, I guess that's OK for workers?
Also sounds like the canvas use case is split for the postMessage latency use case.

[joone]

@noamr, in this offscreen canvas example, long tasks can be randomly executed within the rendering code, affecting the box update, but LoAF is not appliable in this scenario.

https://joone.github.io/web/game_worker/
https://joone.github.io/web/game_worker/game_worker.js

If we support the Long Tasks API in Web Workers, it can identify long tasks in this case.

If you're okay with supporting durationThreshold in the Long Tasks API, I can start working on it.
Yes, the offscreen canvas issue can be affected by rendering latency or delayed postMessage events, so we need ways to easily identify these problems.

[noamr]

@noamr, in this offscreen canvas example, long tasks can be randomly executed within the rendering code, affecting the box update, but LoAF is not appliable in this scenario.

Why is it not applicable? Can you expand?

If you're okay with supporting durationThreshold in the Long Tasks API, I can start working on it. Yes, the offscreen canvas issue can be affected by rendering latency or delayed postMessage events, so we need ways to easily identify these problems.

Not convinced yet that long tasks help identifying or acting on any issues with workers.

[joone]

@noamr, in this offscreen canvas example, long tasks can be randomly executed within the rendering code, affecting the box update, but LoAF is not appliable in this scenario.

Why is it not applicable? Can you expand?

In the demo above, you can move the box using the cursor keys, but it is sluggish due to the Fibonacci function call in the gameLoop(). This issue cannot be identified by the LoAF API.

[noamr]

@noamr, in this offscreen canvas example, long tasks can be randomly executed within the rendering code, affecting the box update, but LoAF is not appliable in this scenario.

Why is it not applicable? Can you expand?

In the demo above, you can move the box using the cursor keys, but it is sluggish due to the Fibonacci function call in the gameLoop(). This issue cannot be identified by the LoAF API.

Why not? If LoAF was supporting workers (instead of long tasks) it should catch that.

[joone]

I hadn't thought about supporting LoAF for Web Workers. If we do, it could help identify the issue.