Monday, January 12, 2009

One event at a time

A design rule I've come to believe in due to painful experience is that it's best to run the code for different purposes independently whenever possible. The Floater bridge software used to break this rule and update the UI in various places while in the middle of serving a network request. Once I changed all of these to run at the next tick of the event loop, it stopped locking up. The Unix Squeak VM used to (and possibly still can) lock up if you resize the window, because at least two different primitives had an internal call to pump the event loop waiting for an event that matches some pattern.

Nowadays I really try to run code from the event loop when possible. It can cause a big decrease in complexity, because each event handler runs in a fresh context with all of the program's invariants established. When implementing code that will run at the top level of the call stack, you don't have to reason about what arbitrary event might already be in progress while trying to run the new one.

Unfortunately, AJAX might strike again against this principle. Eugene Lazutkin has written an in-depth defense of the event-loop architecture I sketch above. Unfortunately, one of the important tools for using this approach is apparently crippled in every single browser:
I ran this code on different browsers and different operating systems and it turned out that all of them have the minimal timeout time. Setting the timeout time lower than that value doesn't reduce the timeout.

"Lower than that value" includes a timeout of 0.

I wonder how hard it would be for GWT to work around this and make zero-timeout events really work?

No comments: