incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Kwiatkowski <>
Subject Re: Actionscript workers and async locking?
Date Mon, 26 Mar 2012 13:12:53 GMT

That's not how I've seen it work.  Each call is blocking on the thread
until the send is complete (the response is in its own thread and will
dispatch an event when the data has been received).  Only one send will
happen at a time.  The receives are not blocking, up to the number of IO
handlers that the browser (or AIR) allocates for network communications
(this is customizeable in some, typically older browsers).


On Mon, Mar 26, 2012 at 4:20 AM, Cosma Colanicchia <>wrote:

> Good point, Justin.
> Note that the "single" concurrency just throws an error if you try to
> invoke a second call while there is another one in progress for the
> same RemoteObject.
> 2012/3/26 Justin Mclean <>:
> > Hi,
> >
> >> I feel like a lot of people tried and are trying to address the
> >> disadvantages of coding async control flows. So I ask myself again:
> >> with worker threads, wouldn't it be simpler to just ask to synchronize
> >> the thread on the async token, i.e. locking it until result/fault?
> >
> > In general this would work for a string of calls one after the other
> where each call depends on the results of  the previous call.
> >
> > However you may want to make 3 async calls and then when you get all 3
> back (which may return in a different order each time) then make another
> call if they all worked.
> >
> > In this case I've at various times used different way of solving this by
> using event maps, counting no of successful calls before making another,
> setting concurrency and made code independent of the order the calls return
> in.
> >
> > I'm not sure that worker threads can really help with making async calls
> (but happy to be convinced otherwise).
> >
> > Re locking there is a property on both the web service and remote
> classes which would act the same way as locking. Just set concurrency to
> "single".
> >
> > Thanks,
> > Justin

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message