--- In [email protected], Gordon Smith <gosm...@...> wrote: >>>>> Yes, that is what Alex is saying. Handler B will not begin before handler A finishes. Event handlers don't get paused. Furthermore, when you (or the Player) calls dispatchEvent(), all the event handlers listening for that event execute before dispatchEvent() returns. >>>>>
I really want to believe this assertion, and I hate to belabor the point, but I'm troubled by the observed behavior in the Debug Player under IE8. In this case, a run-time error was thrown by the handler of a network event and the standard dialog was displayed. This condition exposed a problem in our network message parser, which caused subsequent network events to also display run-time errors. I was unsettled to find that a new dialog was displayed, and a new Windows OS-level thread created with each run-time error, even though I hadn't dismissed the initial error dialog. It appeared that the network event handler code executed and threw a run-time exception with each message received from the network, regardless. This would seem to be an exception to the behavior stated above; does a run-time error dialog cause the execution context to pause and allow other event handlers to be executed? If so, is this only possible in the Debug Player, or do we have to worry about protecting against possible re-entrance in handlers that access global data?
