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: <[email protected]> > 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: <[email protected]> >>> 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 >> >> >> > >
