1433317 - Re-queuing worker runnables when debugger resumes parent window can reorder worker messages

Status: RESOLVED INVALID

(DevTools :: Debugger, enhancement, P2)

Description

[Jim Blandy :jimb]

The strategy suggested for fixing bug 1426467, while it does respect the run-to-completion rule, can cause Worker onmessage handlers to run out of order, as noted in bug 1426467 comment 12.

Copying the description there:

A proposed solution is to change ResumeTimeouts to re-queue the runnable on the
main thread, where it will run after the JavaScript execution interrupted by the
debugger has completed.

This is adequate to ensure we follow the run-to-completion rule. If the parent
hits another breakpoint and is paused again, then the message runnable may get
stashed in mQueuedRunnables again, but either way, it will only ever run when
the parent window isn't paused, directly from the event loop, so it cannot
interrupt any other JavaScript execution in the parent window.

However, this solution is still buggy, because it can reorder messages from the
worker, in the following situation:

- Parent window sends worker messages A and B, and then hits a breakpoint.

- Worker responds to message A.

- Main thread event loop processes the response runnable. Since the parent
  window is paused, the runnable stashes A in mQueuedRunnables.

- Worker responds to message B.

- Before reaching B's runnable, then main thread event loop resumes the parent.
  ResumeTimeouts removes A from mQueuedRunnables and re-enqueues it for the main
  thread --- *after* B.

Comment 1

[Jim Blandy :jimb]

We didn't use this approach to fix bug 1426467, so this is no longer a blocker.