--- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > Jules, I confess I actually misread your original post - I had anticipated > that when an event is despatch it wouldn't be actioned until the current > code section had been completed then the player would act upon events > awaiting despatch. > > On the face of it, if events are despatched and all handlers invoked > synchronously before the next statement runs then there's an opportunity for > an unexpected race condition if handlers are updating the same data > structures as the code that despatched the event. Like you I would be > surprised at this behaviour and I might try and check that out for myself > later today. > > So you are right my comments don't match your findings. I don't have a > problem with the event despatcher invoking all handlers for an event in > sequence - event handling has a predefined order through the display list, > but there's no guarantee that multiple handlers at the same place in the > hierarchy will be invoked in a set sequence. > > I'm somewhat surprised at your assertion that despatching an event will > invoke handlers for that event synchronously - it would be interesting to > get a better handle on this from someone who knows thelow-level mechanism > more intimately than I do. My event handling code doesn't anticipate that > despatched events are handled syncronously and as i've already said, there's > always a danger of an unexpected race condition if that were true. > > In my previous life writing a lot of code running on multiprocessor systems > we took great care to control asynchronous behaviour and to protect data > structures from multiple updates using semaphores. In a faux system like the > flash player, there isn't true concurrency, but if what you say is true > there would be a real potential of getting an unwanted side-effect since > effectively shared data structures would be open to being updated > unexpectedly whenever an event is despatched. > > So, I'm kinda with you.
I actually had this very thing happen in my code a couple of weeks ago. I normally expect that the code in a function will all run as a block unless, of course, I'm calling out to another function. But in one case, one of the statements I was using (addEventListener, I think), opened up enough of a timing "hole" in my code that some other code (not the function that was being added in the event listener, which might have been partially understandable) ran unexpectedly at that point. The only solution I found was to make sure I put all of the other code that _had_ to run in that block before anything else happened above the addEventListener code. -Amy
