GeezerVison

In a debug build, a worker paused at a breakpoint inside console.log (for example a debugger statement in a getter that the message text conversion runs) makes the parent's worker.terminate() block until the debugger resumes, freezing the parent's thread.

WorkerWrapper::ConsoleLog holds inspectorMutex_ across WorkerInspectorClient::consoleLog, so the pause loop runs with that mutex held. Terminate() ends a pause through NotifyTerminating(), which it reaches by taking the same mutex, so it waits for the pause, and the pause only waits for the debugger. The pause loop now also leaves on the worker's own isTerminating_ flag, which Terminate() sets before it takes the mutex and which the loop checks on each pass while it waits. The paused worker then returns from consoleLog, the mutex is released, and Terminate() continues.

This builds on #2067, whose commits are the first three here. Leaving the pause on the flag lets the worker run on to its own teardown while the parent may still be interrupting its isolate, and #2067 is what keeps the isolate alive until the parent is done with it.

With the pause entered by hand at that point, the parent's terminate() on main blocks in mutex::lock() while the worker sits in runMessageLoopOnPause, and with this change it returns and the worker ends. Reproducing it for real needs a DevTools session paused inside the getter, so there is no spec for it. The full device suite passes.

Summary by CodeRabbit

• Bug Fixes
  • Workers can now be terminated reliably after calling close(), including while paused in debugging.
• Tests
  • Added coverage to verify that a closed worker stops running after termination.