Bug 1664386 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Jens Stutte [:jstutte] from comment #2)
> Q3: Isn't it [risky to block the main thread](https://searchfox.org/mozilla-central/rev/8a0745cd346f0cfb89ae71690babbf7bff706113/dom/workers/RuntimeService.cpp#1599-1610) just to compose the worker shutdown hang messages? What if we never receive a response from that worker? Couldn't this cause real process hangs we will never get reports for?

Sortof.  The expected failure mode is that the Worker is responsive but it has effectively leaked a StrongWorkerRef somehow.  The WorkerControlRunnnables will always interrupt running JS, which means that we're not concerned about JS content code being in a tight while loop.  It's also the case that a failure mode where the thread is in an infinite loop will show in the crash stats.
(In reply to Jens Stutte [:jstutte] from comment #2)
> Q3: Isn't it [risky to block the main thread](https://searchfox.org/mozilla-central/rev/8a0745cd346f0cfb89ae71690babbf7bff706113/dom/workers/RuntimeService.cpp#1599-1610) just to compose the worker shutdown hang messages? What if we never receive a response from that worker? Couldn't this cause real process hangs we will never get reports for?

Sortof.  The expected failure mode is that the Worker is responsive but it has effectively leaked a StrongWorkerRef somehow.  The WorkerControlRunnnables will always interrupt running JS, which means that we're not concerned about JS content code being in a tight while loop.  It's also the case that a failure mode where the thread is in an infinite loop will show in the crash stats in the thread backtrace for the worker.

Back to Bug 1664386 Comment 4