Hi Ralf, That's my understanding now too. What I'm slowly coming to terms with are the facts you so lucidly summarise below :)
I (and I think Paul too) had always assumed that control returned from the dispatchEvent function immediately. I'm still a little bit shocked about it. In this light, dispatchEvent just routes function calls through a common object. It's too early to say whether it'll make much difference to how I code in Flex. I hate stories that end with a deus ex machina :) On Wed, Dec 10, 2008 at 02:47, Ralf Bokelberg <[EMAIL PROTECTED]> wrote: > I'm confused. Let's clarify what we are talking about. > > The event dispatching is fully synchronous. > If you call dispatchEvent, all event handlers are called, before the > next statement is executed. > > Some processes (eg loading something from the backend or a timer) > dispatch events in an asynchronous manner. So they call dispatchEvent > at some unknown point in time > > I think, this is how it works. > > Cheers > Ralf. > > On Tue, Dec 9, 2008 at 10:27 AM, 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. >> >> 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 >>> >>> >>> >> >> >
