Cosma, 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).
-Nick On Mon, Mar 26, 2012 at 4:20 AM, Cosma Colanicchia <cosma...@gmail.com>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 <jus...@classsoftware.com>: > > 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 >
