flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Heidegger ...@leichtgewicht.at>
Subject Re: Actionscript workers and async locking?
Date Thu, 22 Mar 2012 09:15:15 GMT
I read into the remoting code recently and I think it certainly is a 
good idea to use threading
for the parsing of the data (big soap files: lot to process). Generally 
speaking: Server side processes
run in a different thread (on the server itself!) and xml/json/etc. is 
just a mean of communication.

It would be awesome to have a api that makes use of the promises:

Promise result = api.operation("1234");

in that way we could "stack" calls to the api and get the results. 
However that would be
a complete rewrite of rpc, which tbh. is not that bad of an idea.


On 22/03/2012 17:37, 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