Javascript blocking wait

Question

I am implementing an interactive debugging facility for code running in a browser. When I get to a "breakpoint" I need to invoke the debugger and wait for the required action that may of course include a "continue" command to go further with the execution of the script.

To do this I've written a small node.js webserver that handles those "debug" requests using a long polling technique. The debugger interface is running in another browser window and talks to the node.js webserver so commands can effectively sent to the script being debugged from the other browser.

The "halt" in the script being debugged is implemented using a synchronous request that takes at most N seconds in a for(;;) loop that can be exited when the command "cont" is received. If the programmer doesn't send a command using the debugger interface within the limit the server automatically sends a "wait more" answer, and the script remains in the endless loop.

Everything works nicely, except that the browser (Chrome in this case) after a while pops up a dialog telling that the script being debugged is stuck and providing options for killing it. This happens no matter what is the value of N.

Is there a way to wait for the command without having the browser to kill the script? Can the timeout be changed?

Note that changing the script to use a callback logic like it's normally done when programming in the browser is impossible (unless you're talking about performing a full CPS transform on a generic program, and I don't want to go there).

Answer 1

You cannot properly halt the script without using the JS debugging interface that is used by browser extensions such as firebug.

Blocking with active waiting as you currently do is a really bad idea since it eats up lots of CPU power and blocks the whole browser (at least in firefox).

• 6502: Are you sure that waiting for a synchronous http get request uses a lot of CPU power?
• ThiefMaster: Ah, mistread your question. I thought you are doing for(;;) to block until e.g. a certain time elapsed. Synchronous XHRs are somewhat better - they still block some browsers but not all and of course they don't waste CPU.
• 6502: Oh... ok. Actually I just made an experiment with Firefox and works nicer than Chrome, of course the CPU is not used but also for example the DOM gets rendered even before the script under debugging is completed. In Chrome instead no repaint happens until the script finished executing.

Answer 2

There is no portable (cross-browser) way to prevent the browser to kill a script when it thinks that execution is taking too much and it's not possible to start a nested event loop to implement blocking operations like it's done normally in GUI libraries.

A solution working for Chrome is just starting the browser with the option

--disable-hang-monitor