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. Paul ----- Original Message ----- From: "Jules Suggate" <[EMAIL PROTECTED]> To: <flexcoders@yahoogroups.com> Sent: Tuesday, December 09, 2008 8:55 AM Subject: Re: [flexcoders] Parsley MVC :: some thoughts > How can something be asynchronous but not concurrent? Asynchronous > means that control returns from the function call immediately although > the transaction triggered by the call may still be ongoing. To me, > that absolutely *requires* concurrency, even if it's simulated through > a timeslicing scheduler or some such. > > I'm pretty sure for something to be asynchronous there has to be some > sort of interleaving. > > That's the whole point of what I just realised: there is no such > interleaving within the Flex framework. Event dispatch in Flex/Flash > is a *blocking* operation. There's no scheduler or anything within the > event bus. Maybe your handlers will make calls to a truly asynchronous > API like network calls or something, but until they make that call and > return control to the code that dispatched the event, the next line of > code in your event producer object will *not* execute. > > I'm just freaked out that I never realised this. How have my > applications even been *usable* until now?!?!? Pure luck.... and good > API design from Adobe/Macromedia. > > Cheers to the Player team! > > On Tue, Dec 9, 2008 at 03:02, Paul Andrews <[EMAIL PROTECTED]> wrote: >> They are asynchronous but they aren't concurrent. >> >> Paul >> >> ----- Original Message ----- >> From: "Jules Suggate" <[EMAIL PROTECTED]> >> To: <flexcoders@yahoogroups.com> >> Sent: Monday, December 08, 2008 1:59 PM >> Subject: Re: [flexcoders] Parsley MVC :: some thoughts >> >>> <boom> head explodes.... heh! >>> >>> I have been happily thinking the whole time that events really *are* >>> asynchronous, but that's obviously not true. Reality check... >>> >>> Thanks guys. I think I might have run out of reasons *not* to use >>> Parsley >>> :) >>> >>> On Tue, Dec 9, 2008 at 01:06, Paul Andrews <[EMAIL PROTECTED]> wrote: >>>> ----- Original Message ----- >>>> From: "Jules Suggate" <[EMAIL PROTECTED]> >>>> To: <flexcoders@yahoogroups.com> >>>> Sent: Monday, December 08, 2008 6:49 AM >>>> Subject: [flexcoders] Parsley MVC :: some thoughts >>>> >>>>> Anyone used Parsley MVC? I'm a bit confused by it. >>>>> >>>>> There's the standard MVC FrontController class, which exposes a method >>>>> dispatchEvent() for app-wide notifications. It also has a concept of >>>>> interceptors which is nice... so far so good. >>>>> >>>>> BUT... that dispatchEvent() call executes *synchronously*. Control >>>>> won't return to your code until *every single listener* to that event >>>>> finishes executing!! In a single-threaded environment like Flash >>>>> Player, I would have thought this to be a disastrous design >>>>> decision... can anyone shed any light on this, as I'm sure there's >>>>> something I'm missing here! >>>> >>>> Why is it disastrous? The flash player is single threaded so it's not >>>> possible have concurrently running code (something I think that Adobe >>>> should >>>> address in the future) so why shouldn't all the waiting listeners be >>>> called? >>>> >>>> It's not possible to resume execution elsewhere while a listener is >>>> still >>>> active because that would require semaphores to handle pseudo >>>> concurrency >>>> and I'm sure that holds true not just for the listeners themselves but >>>> also >>>> for the mechanism that calls the waiting listeners. >>>> >>>> Paul >>>> >>>>> >>>>> TIA, >>>>> +J >>>>> >>>>> PS another thing I haven't figured out yet is how to inject >>>>> dependencies into a View component... it seems Parsley can only inject >>>>> into objects that have been created in the Parsley config file ... and >>>>> because View components are instantiated by the Flex framework, from >>>>> what I can tell Parsley has no way to reference them... this has the >>>>> unpleasant side-effect of requiring all my View code to access the >>>>> FrontController directly through the FrontController.root static >>>>> property. >>>>> >>>>> In fact, the FrontController class is bugging me -- it is a concrete >>>>> class with no abstract interface I can code to. It's making me nervous >>>>> about lock-in to the Parsley framework. >>>>> >>>>> Kinda goes against the whole IoC thing, no? >>>>> >>>>> PPS And yeah, I will post this to the Parsley forums, but I want the >>>>> esteemed opinion of those on this list too! >>>>> >>>>> ------------------------------------ >>>>> >>>>> -- >>>>> Flexcoders Mailing List >>>>> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt >>>>> Alternative FAQ location: >>>>> >>>>> >>>>> https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 >>>>> Search Archives: >>>>> http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups >>>>> Links >>>>> >>>>> >>>>> >>>> >>>> >>> >>> ------------------------------------ >>> >>> -- >>> Flexcoders Mailing List >>> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt >>> Alternative FAQ location: >>> >>> https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 >>> Search Archives: >>> http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups >>> Links >>> >>> >>> >> >> > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Alternative FAQ location: > https://share.acrobat.com/adc/document.do?docid=942dbdc8-e469-446f-b4cf-1e62079f6847 > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > >
