incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Smith <>
Subject Re: Actionscript workers and async locking?
Date Thu, 22 Mar 2012 23:38:08 GMT

It almost seems like most of your problem could be solved through code. 
When I'm bootstrapping an application, I use a task framework to handle 
multiple remoting calls. Most of them have asynchronous tasks. Cairngorm 
3, PureMVC, and Robotlegs all have asynchronous task components 
available, and I imagine the problem has been solved in other frameworks 
as well. You usually end up with some main task class that has a list of 
subtasks, which can by asynchronous or synchronous, or run in sequence 
or parallel. PureMVC's implementation is particularly well done.

Once the tasks are created, you can fire off as many requests as your 
browser will allow in parallel, which usually speeds up bootstrapping 


On 3/22/2012 2:37 AM, Cosma Colanicchia wrote:
> Hi,
> I've read about the new ActionScript workers, coming in one of the
> next releases of the Flash Player: good news.
> I wander if this could enable an improvement related to remoting:
> frequently I need to perform multiple async remote calls to the
> service layer, waiting for the result of one invocation before
> starting the second, and so on. This usually results in a number of
> result and fault event handlers that makes very hard to follow even
> simple logic. Basically, because we miss a "sync remote call"
> facility, or (in other words) the ability to pause the calling thread
> until an async operation is completed.
> I understand that with the current single-thread model this is
> undesiderable, because locking the (only) thread would lock the entire
> ActionScript execution, including UI refresh, blocking the user on the
> current frame.
> However, this could be a very useful feature in a worker thread,
> because it would lock only that thread, without any impact on the app
> responsiveness. I mean the ability to write something like:
> public function mySyncFunction(value:String):String {
>    var firstToken:AsyncToken = myService.getOperation("firstMethod").send(value);
>    lockForToken(firstToken); // allowed only in a worker
>    var firstMethodResult:String = firstToken.result as String;
>    var secondToken:AsyncToken =
> myService.getOperation("secondMethod").send(firstMethodResult);
>    lockForToken(secondToken); // allowed only in a worker
>    return secondToken.result as String;
> }
> The same logic, implemented in the current way, usually requires 6
> more methods (or closures): 4 to manage the faults/results of the
> remote invocations, and 2 event handlers to receive the async result
> of mySyncFunction. The added bonus of this feature would be that, in a
> worker thread, we would be able to "break the async inheritance" that
> currently force any method that use an async method (directly or
> indirecty, anywhere in the nested call hierarchy) to be coded as an
> async method itself.
> I know this is flash player stuff, and that in the provided sample
> there seems to be some "magic" in the asynctoken that would rather
> belong to a synchronization primitive.. I just wanted to know what do
> you think about the concept.
> Cosma

View raw message