You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Cosma Colanicchia <co...@gmail.com> on 2012/03/22 09:37:35 UTC
Actionscript workers and async locking?
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
Re: Actionscript workers and async locking?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
As far as I know a "Promise" of the new Thread api is built on events.
As fas as I can tell from the presentation @ max2011 the new threading
api will be a non-shared model (much unlike java). The (very) nice thing
about Promises is that they can be taken for server-side requests too:
Which is why I suggested an rpc-api that is similar.
yours
Martin.
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
I seriously don't know... I see all these "solutions" as attempts at fixing
something that isn't broken, so I wouldn't use any because, frankly, I
think that evens / event dispatcher is a more generic, more simple to use
and more idiomatic way to do this in Flash. Why on earth do you want to do
something instead of it?
This reminds me of how almost every newcomer to Lisp tries to come up with
some reader macros that allows use of infix operators, because newcomers
are annoyed about that math isn't written precisely the same as it appears
in their textbooks (+xy instead of x+y). It is possible to do, but is a
waste of time. It's something that the said enthusiastic programmer will
abandon in a couple of months and will never use again.
To continue the illustration of the example with errors: what if you were
using a socket, where errors are fine some times, but they don't happen as
often as you receive data. Besides, you may receive plenty of different
errors and plenty of different messages, which you don't want to handle all
in one place. If you will try to make it linear, you'll end with something
like this:
for (...) {
try { message = socket.readMessage(); }
catch (error0:IOError) { /* handle IOError */ }
catch (error1:SecurityError) { /* handle SecurityError needs to use some
code from IOError clause, ouch! */ }
catch (error2:ParsingError) { /* handle ParsingError */ }
/* here you already don't know what to do with the message and whether you
didn't get here by mistake */
}
This is a typical Java-style mess. What if two errors happened at the same
time? Why would anyone want this instead of having handlers?
EventDispatcher offers you an abstraction, something that spares you
writing the for loop and implementing complex interoperability of different
handlers you would otherwise create ad hoc in every function of the similar
nature.
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> 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.
I thought it queued up the request (it's has been a while since I've used it in anger). I've checked the docs and yes it seems the calls will fail right away if you make another call - although I've not tested this.
Perhaps we need to add concurrency="queued" or equiv to RemoteObject?
Thanks,
Justin
Re: Actionscript workers and async locking?
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
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 <co...@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 <ju...@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
>
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
> is now forced to return an AsyncToken object
That's some behavior typical of Flex framework. RemoteObject is rather an
exception to the common practice, then an example of it. You can't really
make generalization about how RPC works in Flash based on what it does,
more so, it's better that you don't. Normally, you use events / callbacks.
It is really similar to the way monads are used in Haskell - it's an
uncomfortable concept for people unfamiliar with the language, but after
you get used to it, it's fine. There are problems that could be better
solved by having a persistent state, but the language doesn't offer a
persistent state. Same thing with event handlers. It is not extremely
straight forward, but you don't really have any other option given the
entire language structure.
I've nothing to say about other OOP-facade-encapsulation-buzzword stuff, as
these words just sound arbitrary in this context. I think you have taken a
wrong example to begin with and your further assumptions are thus missing
the point. Honestly, RemoteObject isn't even a good way to go about RPC in
Flash, it's some concept borrowed from ColdFusion templates or something
like that... it's relevance to Flash / AS3 is fictional...
And, again, no, what you offer is neither simpler nor more efficient, nor
more idiomatic for the language. You are mistaking, if you think that it is
simpler because you don't account for the situations that must be taken
into account. You are trying to simplify something which cannot be
simplified to this level.
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Taylor Brown <ta...@taytay.com>.
Have you all seen this "Promises" AS3 api?
https://github.com/CodeCatalyst/promise-as3/tree/develop
I just discovered it, but it looks pretty darn nice.
@Cosma, your initial "locking" code example reminds me of the new "await"
keyword in C#:
http://msdn.microsoft.com/en-us/library/hh156528(v=vs.110).aspx
This also reminds me of "Reactive Extensions", which was a library that
attempted to address some of the issues with asynchronous spaghetti. It was
originally a .NET project, but it's been ported to AS3. (AS3
Implementation: https://github.com/richardszalay/raix) It's been a while
since I looked at it, but I recall that reactive programming was an
interesting way of looking at asynchronous code. Although I remember it
making some things easier to read, the learning curve was steep (to my mind
anyway), and the end result didn't feel particularly readable. @Justin
mentioned the problem of having 3 separate calls that need to return before
the 4th call can be made, and that is one of the things that I recall
Reactive Extensions could solve specifically. In fact, Reactive Extensions
were specifically good at taking multiple asynchronous streams of results
and combining them in different ways.
I wrote a library to make it easier to write pseudo/cooperative "threads"
in AS3: https://github.com/Taytay/CoThreadAS3
It's good at splitting it up a task so that it runs like a background
thread that still reads linearly. (Granted, this will be obsolete once
worker threads get here). After reading about all of these asynchronous
concepts again though, it makes me want to revisit my library and express
some of the API in terms of Promises. I think it would simplify things a
great deal.
Cheers,
Taylor Brown
On Mon, Mar 26, 2012 at 1:11 PM, Cosma Colanicchia <co...@gmail.com>wrote:
> @Martin
>
> > A DSL for lazy operations has proven itself quite valuable as you can se
> > from the various tweening apis they may be a little wasteful but
> > ultimately result in more stable, flexible systems that are easier to
> read.
>
> In alternative to "real" synchronized methods, I agree that a powerful
> DSL for lazy operations would be really useful... this could also be
> more in line with the current async approach.
>
>
> Cosma
>
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@Martin
> A DSL for lazy operations has proven itself quite valuable as you can se
> from the various tweening apis they may be a little wasteful but
> ultimately result in more stable, flexible systems that are easier to read.
In alternative to "real" synchronized methods, I agree that a powerful
DSL for lazy operations would be really useful... this could also be
more in line with the current async approach.
Cosma
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@LeftRight:
> [...] what I'm trying to say is that the perceived simplicity
> of another approach is not such. The entire process is more complex, and
> you cannot reduce it's complexity beyond certain level [...]
I agree - even if I didn't explicitly expressed it, my code sample
just wasn't a real change proposal, rather just a code hint to better
explain what I was talking about. There will be other complexities?
Probably yes - I'd like to have the chance to evaluate them and make a
choice before trashing any alternative approach.
> [...] Well, you shouldn't return anything from an event handler, that's the
> limitation of the system, however it doesn't affect the type check, because
> you don't expect handlers to return anything anyway [...]
Not clear about your answer here. I was talking about the return type
of the async method itself.. any async method (because it is a remote
call, or because it contains a remote call) is now forced to return an
AsyncToken object, thus it cannot have a real return type in its
signature.
To make it more clear: if you write a facade/proxy/stub for a
RemoteObject, you can obtain compile-time checking for the method name
and its arguments, but you need to return an AsyncToken, thus no check
on return value (unless you create a lot of AsyncToken wrappers for
each possible return type).
This is also related to another async effect: limited OOP
incapsulation. If you have an object whose external interface is
designed to return a value in a synchronous way, subclasses won't be
able to provide an implementation that is dependent on an asynchronous
invocation (since you can't change the return type signature from the
original type to AsyncToken).
I had to deal with this kind of limitation recently: one of the Flex
OLAP API (crossjoining of two set of tuples) is currently implemented
as a normal, synchronous method. I had to re-implement it using the
green threading approach to support large cubes, thus making it async
in the process: I had to create a different method (instead of
overriding the existing one) and restructure the entire call hierarchy
of the client code to support this new async logic, even if it was
incapsulated behind extendable classes and interfaces. A lot of other
methods need to be refactored as async methods too because they,
directly or indirectly, used the modified version of the method,
because async methods are someway "viral": without a "synchronize"
primitive, they propagate up into the call hierarchy.
> There is yet another concern. Older languages, such as C++ illustrated that
> when you have an API that duplicates another API, the language overall
> becomes more complex and the programmers will become superstitious about
> one kind of the API.
In a general way I share your concerns, but I really don't see any
"duplicated API" here, just a new primitive that could open up a
different approach to a known issue.
> I don't see any benefit of your approach compared to
> what already exists. Having two different approaches is worse then having
> only one in this particular case.
I tried to explain the benefit, I think it is pretty clear: simplified
control flow (expressed by 1 linear method vs a chain of listener
methods referencing each other) and, as positive side effects,
compile-time checking of return values for "resynchronized" methods
and improved OOP abstraction/incapsulation in some async-related
scenarios.
Cosma
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
Cosma Colanicchia, what I'm trying to say is that the perceived simplicity
of another approach is not such. The entire process is more complex, and
you cannot reduce it's complexity beyond certain level. Granted the
approach you illustrated, certain essential parts will be lost. This is the
situation called "leaky abstractions", i.e. when an attempt to abstract
further (an attempt to reduce complexity in this case) will produce more
problems then it solves.
What you are trying to show as simple doesn't have necessary parts any
non-trivial program will require. When these parts are added, the solution
you suggest will not be any less complex then the existing one, more so, it
will probably more complex and clumsy because it is not designed to handle
the real life situations.
Well, you shouldn't return anything from an event handler, that's the
limitation of the system, however it doesn't affect the type check, because
you don't expect handlers to return anything anyway (you are never in a
situation that would allow you to expect anything to be returned from a
handler). Same thing about if blocks or loop blocks - they don't return
anything in AS3. This is unfortunate, but this is a limitation of the
system. Trying to lift this limitation would result in a more complex
implementation, possibly, the results aren't worth the effort.
There is yet another concern. Older languages, such as C++ illustrated that
when you have an API that duplicates another API, the language overall
becomes more complex and the programmers will become superstitious about
one kind of the API. I don't see any benefit of your approach compared to
what already exists. Having two different approaches is worse then having
only one in this particular case.
In any case, I think I said this already. If and when there will be threads
/ workers / processes / w/e it'll be called, what you suggest will
certainly get used a lot, because it's something that, on the surface of
it, is "asking to be done". So that will be another case of newbies coming
to forums / irc for help and being educated not to do it in the way you
suggest because of non-obvious complications that will certainly happen.
It's the same case as it is today with anonymous functions, use of 'with'
construct etc - something that on the surface of it should make the work
easier, but in reality complicates it that much, you would rather avoid it
as a rule.
---
Martin,
This suggest reduced quality in exchange for simpler implementation -
something that I personally wouldn't accept, but I'm not arguing this
should be the case for everyone.
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@LeftRight: I agree that event-based async methods are more idiomatic,
but my opinion is that they are more simple to use only in a limited
use cases. If you take the scenario I described (if f(x) return g(x)
else return h(x)" with f, g and h being async operations) that is not
very complex, yet it require the definition of 4-5 additional
methods/closures with the normal approach. Also, any async operation
currently cannot be statically typed (you cannot put the real
"returned type" in method signatures that involves async operations),
loosing readability and compile-time check.
2012/3/26 Justin Mclean <ju...@classsoftware.com>:
> Hi,
>
> You might want to note that RemoteObject does throw an errors on faults if no event handler has been set up. Take a look at dispatchEvent in RemoteObject. Again not tested just looked at the source but from memory that's the behaviour.
>
> Thanks,
> Justin
Re: Actionscript workers and async locking?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
On 26/03/2012 18:13, Left Right wrote:
> Martin: what particularly would bother me about such model is the energetic
> style (energetic as opposite of lazy). I.e. in your scenario {x: 200}
> object is created even before the first function runs. In case there is an
> error, creation of this object may not be necessary, but it was already
> created. This is why I mentioned Erlan-style processes, where the code that
> needs to be executed in response to a signal isn't evaluated until the
> signal is received.
Any configuration process is always bound to "unnecessary
instantiation", if you instantiate
things only when needed then you have to pay a lot of intention to what
properties are available at what time.
A DSL for lazy operations has proven itself quite valuable as you can
see from the various tweening apis
they may be a little wasteful but ultimately result in more stable,
flexible systems that are easier to read.
yours
Martin.
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
Martin: what particularly would bother me about such model is the energetic
style (energetic as opposite of lazy). I.e. in your scenario {x: 200}
object is created even before the first function runs. In case there is an
error, creation of this object may not be necessary, but it was already
created. This is why I mentioned Erlan-style processes, where the code that
needs to be executed in response to a signal isn't evaluated until the
signal is received.
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
You might want to note that RemoteObject does throw an errors on faults if no event handler has been set up. Take a look at dispatchEvent in RemoteObject. Again not tested just looked at the source but from memory that's the behaviour.
Thanks,
Justin
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
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 <ju...@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
Re: Actionscript workers and async locking?
Posted by Justin Mclean <ju...@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
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@LeftRight: about faults.. the first idea on my mind was simply
translating fault events into standard Error throwing, so you can use
normal try/catch logic to handle failed sequences instead of
explicitly analyzing the result of each "synchronized" invocation.
@Robert: exactly, I don't really care about improving response time,
I'd just like to write this kind of logic in a linear method instead
of having it scattered in multiple event listener methods.. it's about
code readability and verbosity. Thanks very much for the links, I'm
going to read it carefully.
@Roland: as3commons-async looks nice, it looks that they are trying,
with the Task class, to mitigate the same pain I was talking about. I
think that, without any real "thread locking" API, it can't get much
better than this.
@Martin: that would be an improvement: using premises instead of
creating a lot of ICountProvider and IConditionProvider to express
control flows (probably, they could be built on top of these
interfaces).
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?
Cosma
2012/3/26 Justin Mclean <ju...@classsoftware.com>:
> Hi,
>
>> It sounds like you really can't do much about the timing of your bootstrap if one call is dependent upon the result of your prior call. Even if you had threads available, you'd be waiting the same amount of time.
>
> Event maps in the Mate framework I find quite useful for this sort of issue (http://mate.asfusion.com/).
>
> Here's a code snippet (from an old Flex3 project I had lying about so might be a little out of date) that give you a feel for event maps in Mate:
>
> <EventHandlers type="{LoginEvent.ATTEMPT_USERLOGIN}">
> <RemoteObjectInvoker instance="{service.loginService}" method="getLoggedOnUser">
> <resultHandlers>
> <MethodInvoker generator="{SelfRegWizard}" method="loginAccountStatus" arguments="{resultObject}" />
> </resultHandlers>
> <faultHandlers>
> <EventAnnouncer generator="{ReportEvent}" constructorArguments="{[ReportEvent.WARNING, 'loginFailed', 'Login Failed']}" />
> </faultHandlers>
> </RemoteObjectInvoker>
> </EventHandlers>
>
> <EventHandlers type="{LoginEvent.SUCCESSFUL_LOGIN}">
> <RemoteObjectInvoker instance="{service.loginService}" method="getLoggedOnUser">
> <resultHandlers>
> <PropertySetter generator="{SelfRegWizard}" sourceKey="{selfRegModel.newAccount}" targetKey="newAccount"/>
> </resultHandlers>
> </RemoteObjectInvoker>
> </EventHandlers>
>
> Thanks,
> Justin
Re: Actionscript workers and async locking?
Posted by Omar Gonzalez <om...@gmail.com>.
>
> I thought this thread was about async programming and not about trashing
> Parsley?
> Seriously, the whole pro- or con- micro-architecture framework discussion
> is rather
> pointless, at the end of the day its a matter of preference.
>
> Just my two cents...
>
> Roland
>
That's what I thought. That's why I specifically linked to the Task
framework. Not the Parsley homepage. You can use their task framework
specifically for coding asynchronous tasks.
The pro/con framework discussion is off topic in this thread.
-omar
Re: Actionscript workers and async locking?
Posted by Roland Zwaga <ro...@stackandheap.com>.
>
>
> > Suddenly you have a huge mess of callbacks you have to reorganize.
>
> No, I don't have a mess, I keep my code well organized. On the contrary,
> Spicefactory code is always a mess, from the very start and it's not
> possible to fix.
>
> What you call "very easily" is your perception of reality, because
> operating plain event handlers is, in fact, much easier then what Parsley
> offers.The very simple proof to it is the reduced code surface (when not
> using Parsley), improved intellisense (when not using Parsley), conscious
> and well accepted techniques employed for writing the code (bizarre / not
> idiomatic techniques are used in Parsley, they borrow heavily from other
> languages and environments, but are foreign to AS3 / Flash), improved
> debugging abilities (when not using Parsley).
>
> People often times want to believe every single thing written on the
> internet - Parsley advertising Parsley is just another random writing on
> the internet, as baseless and pointless as your next Myspace profile. This
> doesn't apply to Parsley exclusively. At the same measure it applies to
> every "microacitecture framework", because architecture cannot be canned in
> the form of a library that you plug to your project. You will get spaghetti
> code with or without using any "microacitecture framework" with exactly the
> same probability.
I thought this thread was about async programming and not about trashing
Parsley?
Seriously, the whole pro- or con- micro-architecture framework discussion
is rather
pointless, at the end of the day its a matter of preference.
Just my two cents...
Roland
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
This thread is heavily OT anyway, because nor the threading, neither
architecture frameworks are anywhere near the purpose of the project :)
Well, I cannot force better choices on anyone... I tried to be a vicar in
my life, no, seriously I did! I know how tough it may get... Besides, i
didn't say that Parsley is absolutely useless, if you look at it from the
financial point of view, it actually helps allocating more working hours to
the project => more funding => better salary / more people get employed.
And I'm the last person to tell someone to work less and be paid less!
Just to make clear one aspect: I told that I would be happier with the
Erlang process/signals (now read attentively:) because it is similar in
principle to how Flash events work. But then again, no one is going to ask
me or even consider my opinion on the subject, so this isn't even a
speculation, it's more like romance/fiction novel :)
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Omar Gonzalez <om...@gmail.com>.
>
>
>>
>> People often times want to believe every single thing written on the
>> internet - Parsley advertising Parsley is just another random writing on
>> the internet, as baseless and pointless as your next Myspace profile.
>
>
> I don't know what MySpace has to do with anything, and I do not work for
> Parsley nor have I ever so I don't know what Parsley advertising has to do
> with anything. I'm speaking from a few years of experience in using Parsley
> for lots and lots of projects over the years. I couldn't care less what
> anyone says about their frameworks, its my experience using those
> frameworks that molds my perception of them.
>
>
And to be clear, I was not speaking earlier about the entire Parsley
package. I've never used the lot of it, I've only used the Task framework.
Which is a very small number of classes for dealing with asynchronous tasks
specifically. I don't know anything about the rest of Parsley.
-omar
Re: Actionscript workers and async locking?
Posted by Omar Gonzalez <om...@gmail.com>.
On Mon, Mar 26, 2012 at 9:11 AM, Left Right <ol...@gmail.com> wrote:
> > Suddenly you have a huge mess of callbacks you have to reorganize.
>
> No, I don't have a mess, I keep my code well organized. On the contrary,
> Spicefactory code is always a mess, from the very start and it's not
> possible to fix.
>
Like they say, beauty is in the eye of the beholder. I've always thought it
was a good solution, and not because of their advertising but because of my
years of using it.
>
> What you call "very easily" is your perception of reality, because
> operating plain event handlers is, in fact, much easier then what Parsley
> offers.The very simple proof to it is the reduced code surface (when not
> using Parsley), improved intellisense (when not using Parsley),
Yep, that's my opinion. Sure event handlers are native, but following one
callback into another callback into another callback, to me, is more
cumbersome than looking at 3 lines of code, one after the other, and know
they are being executed in that order.
> conscious
> and well accepted techniques employed for writing the code (bizarre / not
> idiomatic techniques are used in Parsley, they borrow heavily from other
> languages and environments
Wat?
Weren't you used proposing earlier we borrow from Erlang?
> , but are foreign to AS3 / Flash), improved
> debugging abilities (when not using Parsley).
>
> People often times want to believe every single thing written on the
> internet - Parsley advertising Parsley is just another random writing on
> the internet, as baseless and pointless as your next Myspace profile.
I don't know what MySpace has to do with anything, and I do not work for
Parsley nor have I ever so I don't know what Parsley advertising has to do
with anything. I'm speaking from a few years of experience in using Parsley
for lots and lots of projects over the years. I couldn't care less what
anyone says about their frameworks, its my experience using those
frameworks that molds my perception of them.
> This
> doesn't apply to Parsley exclusively. At the same measure it applies to
> every "microacitecture framework", because architecture cannot be canned in
> the form of a library that you plug to your project. You will get spaghetti
> code with or without using any "microacitecture framework" with exactly the
> same probability.
>
I disagree. Frameworks help me to abstract common patterns so that I can
concentrate my brain cycles on the more important minutia of app building.
As they say, different strokes for different folks.
-omar
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
> Suddenly you have a huge mess of callbacks you have to reorganize.
No, I don't have a mess, I keep my code well organized. On the contrary,
Spicefactory code is always a mess, from the very start and it's not
possible to fix.
What you call "very easily" is your perception of reality, because
operating plain event handlers is, in fact, much easier then what Parsley
offers.The very simple proof to it is the reduced code surface (when not
using Parsley), improved intellisense (when not using Parsley), conscious
and well accepted techniques employed for writing the code (bizarre / not
idiomatic techniques are used in Parsley, they borrow heavily from other
languages and environments, but are foreign to AS3 / Flash), improved
debugging abilities (when not using Parsley).
People often times want to believe every single thing written on the
internet - Parsley advertising Parsley is just another random writing on
the internet, as baseless and pointless as your next Myspace profile. This
doesn't apply to Parsley exclusively. At the same measure it applies to
every "microacitecture framework", because architecture cannot be canned in
the form of a library that you plug to your project. You will get spaghetti
code with or without using any "microacitecture framework" with exactly the
same probability.
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Omar Gonzalez <om...@gmail.com>.
>
> The time you would need to debug this nice piece of software would
> be exponentially larger then if you just used events / event dispatcher.
> Though, on the other hand, if you don't work hard, it's difficult to
> convince the management your work is worth the money they charge for it :)
>
> Best.
>
> Oleg
>
The problem with chaining calls using event/event dispatcher is that you
are essentially building what I like to call event-based-spaghetti-code.
For example, say you need to make ten calls one after the other as they are
dependent on each other in a certain order. Then a month later a new call
needs to be implemented within this chain and some calls need reordering.
Suddenly you have a huge mess of callbacks you have to reorganize. Sure its
not too hard, but when I'm in the middle of a 10 day sprint I don't have
time to fiddle around with trying to order callbacks to chain properly.
Using something like the Task framework from Spicelib (
http://www.spicefactory.org/parsley/docs/2.3/manual/task.php) you can very
easily move tasks around in order simply by moving an addTask() call
up/down a line or two. These tasks are still event based, they just provide
a nice API for setting up the order of tasks that need to be performed.
-omar
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
Tink,
Well, what I was saying is that when you hear the word "standard" in the
context of programming, you want to think about a group of professors of
computer science gathering together and postulating the ultimate truth.
This is while the code of any microachitecture framework looks more like an
abstract from Andre Breton's book... (I love him dearly, a good man he was!)
So Parlsey's standard command is more like the standard speed of a UFO,
really - I guess they usually travel at the double speed of light, don't
they? :)
Very recently I had an extremely pleasant experience of inheriting a
project that used Parsley. I spent about two month until I could totally
remove Parsley from the project. When I finally removed the last reference
to Spicefactory, I compared the size of the produced binary and it was
roughly the size of the binary before removal sans the size of Parsley
library and what I estimated to be the required implementation. By the time
of removal, I also eventually fixed several bugs caused by the use of the
said "framework". On the next iteration planning day I was told that it was
a bad thing to do, because now I need another filler for the time allocated
for the project (otherwise, if we finish ahead of time, we would get extra
load of work, and, most importantly, our project budget would be reduced).
Parsley would otherwise provide a good source of bugs and extra work - so I
was tasked to find a replacement, immediately.
What you posted, as you well know is only the top of the iceberg, the
required amount of code to support this construction is nearly ten times
bigger. The time you would need to debug this nice piece of software would
be exponentially larger then if you just used events / event dispatcher.
Though, on the other hand, if you don't work hard, it's difficult to
convince the management your work is worth the money they charge for it :)
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@Nicholas: now I get it, but that wasn't my suspicions, I was just
reporting the docs [1] for the "single" concurrency type:
"single - Making only one request at a time is allowed on the method;
additional requests made while a request is outstanding are
immediately faulted on the client and are not sent to the server."
[1]http://help.adobe.com/it_IT/FlashPlatform/reference/actionscript/3/mx/rpc/remoting/RemoteObject.html#concurrency
Ciao,
Cosma
2012/3/26 Nicholas Kwiatkowski <ni...@spoon.as>:
> That was in regard to your suspicions on how the RemoteObject class worked.
> You should that if you sent it two command to process, the second would
> error out --
>
> -Nick
>
> On Mon, Mar 26, 2012 at 9:21 AM, Cosma Colanicchia <co...@gmail.com>wrote:
>
>> @Nicholas: I suspect a misunderstanding, I was talking about the C#
>> "await" (just copied and pasted from the link provided by Taylor)...
>> what exactly is "that's not how I've seen it work"?
>>
>>
>> Cosma
>>
Re: Actionscript workers and async locking?
Posted by Nicholas Kwiatkowski <ni...@spoon.as>.
That was in regard to your suspicions on how the RemoteObject class worked.
You should that if you sent it two command to process, the second would
error out --
-Nick
On Mon, Mar 26, 2012 at 9:21 AM, Cosma Colanicchia <co...@gmail.com>wrote:
> @Nicholas: I suspect a misunderstanding, I was talking about the C#
> "await" (just copied and pasted from the link provided by Taylor)...
> what exactly is "that's not how I've seen it work"?
>
>
> Cosma
>
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@Nicholas: I suspect a misunderstanding, I was talking about the C#
"await" (just copied and pasted from the link provided by Taylor)...
what exactly is "that's not how I've seen it work"?
Cosma
Re: Actionscript workers and async locking?
Posted by Tink <fl...@tink.ws>.
On 26 Mar 2012, at 13:57, Cosma Colanicchia wrote:
>> Sorry, this may be more typical of C/C++ people, but it's almost a
>> subject
>> worth an xkcd comic... Every time I hear the word "standard" I
>> expect it to
>> be followed by ISO / ASCII / ISBN or similar set of capital roman
>> letters
>> and a number. :) Parsley is not a standard and it's commands are no
>> more
>> standards then my five spoons of sugar I put into my espresso cup.
>
> I'm almost sure that "standard Parsley commands" was really meaning
> "plain, normal Parsley commands", not "standard" in the "ISO standard"
> acceptation...
>
> But I like xkcd too :)
>
>
> Cosma
Yeah
"standard Parsley commands"
not
"standard commands"
;)
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
> Sorry, this may be more typical of C/C++ people, but it's almost a subject
> worth an xkcd comic... Every time I hear the word "standard" I expect it to
> be followed by ISO / ASCII / ISBN or similar set of capital roman letters
> and a number. :) Parsley is not a standard and it's commands are no more
> standards then my five spoons of sugar I put into my espresso cup.
I'm almost sure that "standard Parsley commands" was really meaning
"plain, normal Parsley commands", not "standard" in the "ISO standard"
acceptation...
But I like xkcd too :)
Cosma
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
@Tink: I see that pratically *all* the application frameworks designed
for Flex try to address this requirements someway.
@Taylor: I was talking about something that looks like C# "await", yes:
"The await operator is applied to a task in an asynchronous method to
suspend the execution of the method until the awaited task completes.
[...]
The asynchronous method in which await is used must be modified by the
async keyword [...]
An await expression does not block the thread on which it is
executing. Instead, it causes the compiler to sign up the rest of the
async method as a continuation on the awaited task. Control then
returns to the caller of the async method. When the task completes, it
invokes its continuation, and execution of the async method resumes
where it left off."
This is a nice tradeoff:
- no real thread locking
- the entire method is still async (caller receive a sort of "token"
immediately)
- you use a better, concies, readable syntax for flow control in set
of async operations
- the compiler/runtime hides the complexity (reducing the verbosity
of the code)
This solution does not not requires "worker threads", and maybe could
theoretically be implemented without additional runtime support (only
on compiler/bytecode generation level)
Very nice links and information, thank you.
@LeftRight: If I understand your position correctly, you say that
already is already ok regarding RPC/async, and that everything else
would increase complexity and/or make language worse.. its would be a
legit point or view, I simply do not agree with it. The fact that a
lot of frameworks try to address this issue, and that other languages
offer low-level or high-level syntax/language tools to deal with it,
makes me think that it is not just buzzword talking, but a real
requirements for real applications.
Bye,
Cosma
2012/3/26 Left Right <ol...@gmail.com>:
>> Parsley also supports this stuff. Parsley 3.0 is especially nice as
>> instead of being dependent on tasks (which the previous version relied on),
>> you can re-use you standard Parsley commands.
>>
>
> Sorry, this may be more typical of C/C++ people, but it's almost a subject
> worth an xkcd comic... Every time I hear the word "standard" I expect it to
> be followed by ISO / ASCII / ISBN or similar set of capital roman letters
> and a number. :) Parsley is not a standard and it's commands are no more
> standards then my five spoons of sugar I put into my espresso cup.
>
> In order to continue in the spirit of xkcd and standards compliance,
> there's this RFC-1925 http://tools.ietf.org/html/rfc1925 paragraph 6a that
> states that:
>
> It is always possible to add another level of indirection.
>
> This is the only RFC or standard that Parsley follows most fully and
> unconditionally.
>
> Sorry, unforgettable personal experience with this particular piece of
> software made me post this comment. I apologize beforehand for any such or
> similar experiences caused by the comment! :)
>
> Best.
>
> Oleg
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
> Parsley also supports this stuff. Parsley 3.0 is especially nice as
> instead of being dependent on tasks (which the previous version relied on),
> you can re-use you standard Parsley commands.
>
Sorry, this may be more typical of C/C++ people, but it's almost a subject
worth an xkcd comic... Every time I hear the word "standard" I expect it to
be followed by ISO / ASCII / ISBN or similar set of capital roman letters
and a number. :) Parsley is not a standard and it's commands are no more
standards then my five spoons of sugar I put into my espresso cup.
In order to continue in the spirit of xkcd and standards compliance,
there's this RFC-1925 http://tools.ietf.org/html/rfc1925 paragraph 6a that
states that:
It is always possible to add another level of indirection.
This is the only RFC or standard that Parsley follows most fully and
unconditionally.
Sorry, unforgettable personal experience with this particular piece of
software made me post this comment. I apologize beforehand for any such or
similar experiences caused by the comment! :)
Best.
Oleg
Re: Actionscript workers and async locking?
Posted by Tink <fl...@tink.ws>.
Parsley also supports this stuff. Parsley 3.0 is especially nice as
instead of being dependent on tasks (which the previous version relied
on), you can re-use you standard Parsley commands.
So you can do this sort of thing:
<parsley:MapCommand messageType="{StartupMessage}">
<parsley:CommandSequence>
<parsley:Command type="{ParseFlashVars}"/>
<parsley:Command type="{LoginCommand}"/>
<parsley:ParallelCommands>
<parsley:Command type="{LoadUserProfileCommand}"/>
<parsley:Command type="{LoadPrivateMailboxCommand}"/>
</parsley:ParallelCommands
<parsley:Command type="{StartAppCommand}"/>
</parsley:CommandSequence>
</parsley:MapCommand>
http://www.spicefactory.org/parsley/docs/3.0/manual/managedcommands.php#flows
Tink
Re: Actionscript workers and async locking?
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> It sounds like you really can't do much about the timing of your bootstrap if one call is dependent upon the result of your prior call. Even if you had threads available, you'd be waiting the same amount of time.
Event maps in the Mate framework I find quite useful for this sort of issue (http://mate.asfusion.com/).
Here's a code snippet (from an old Flex3 project I had lying about so might be a little out of date) that give you a feel for event maps in Mate:
<EventHandlers type="{LoginEvent.ATTEMPT_USERLOGIN}">
<RemoteObjectInvoker instance="{service.loginService}" method="getLoggedOnUser">
<resultHandlers>
<MethodInvoker generator="{SelfRegWizard}" method="loginAccountStatus" arguments="{resultObject}" />
</resultHandlers>
<faultHandlers>
<EventAnnouncer generator="{ReportEvent}" constructorArguments="{[ReportEvent.WARNING, 'loginFailed', 'Login Failed']}" />
</faultHandlers>
</RemoteObjectInvoker>
</EventHandlers>
<EventHandlers type="{LoginEvent.SUCCESSFUL_LOGIN}">
<RemoteObjectInvoker instance="{service.loginService}" method="getLoggedOnUser">
<resultHandlers>
<PropertySetter generator="{SelfRegWizard}" sourceKey="{selfRegModel.newAccount}" targetKey="newAccount"/>
</resultHandlers>
</RemoteObjectInvoker>
</EventHandlers>
Thanks,
Justin
Re: Actionscript workers and async locking?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
After having a deeper look at as3commons-async I think it is pretty
unmature, however: I actually quite like the new threading API that uses
promises.
Imagine:
var serial: Async = new Async();
serial.
.next( thread.doSomething() ) // passes the Promise from
"thread.doSomething" to the chain and waits for the execution
.error( handleErrorOfTheThread ) // handles a error message
from the former thread result
.next( loadFile("myAwesomeFile") ) // instantiates a url
loading process and creates a Promise that it will return the File...
.error( Async.INTERRUPT ) // Any error that happens here
causes to interrupt the staple execution
.handle( createGUI ) // gets the File passed on success and
instantiates a class
.next( animate( gui, {x: 200} ); // lets the gui slide in
(also creates the promise that its there
.revert( animate( gui, {x: -100} ); // to be called if the
"Async" task was canceled for some reason
.next( guiDone );
If all those methods would return "Promises" (Yeah, I will pass that
file some day) then Threads could be easily integrated with other async
calls.
wouldn't that be cool ?! ;)
yours
Martin.
Re: Actionscript workers and async locking?
Posted by Roland Zwaga <ro...@stackandheap.com>.
On 24 March 2012 19:42, Robert Smith <ro...@thedevprocess.com> wrote:
> Hi Cosma,
>
> It sounds like you really can't do much about the timing of your bootstrap
> if one call is dependent upon the result of your prior call. Even if you
> had threads available, you'd be waiting the same amount of time. So, I'm
> thinking the best you're going to get at this point is some nice code
> organization that is easy to follow. Here are some resources I've found
> helpful.
>
> Cairngorm 3 Task framework - http://sourceforge.net/adobe/**
> cairngorm/wiki/**CairngormLibraries/<http://sourceforge.net/adobe/cairngorm/wiki/CairngormLibraries/>
> PureMVC (framework dependent) - http://trac.puremvc.org/**
> Utility_AS3_AsyncCommand<http://trac.puremvc.org/Utility_AS3_AsyncCommand>
> Robotlegs (framework dependent) - http://aaronhardy.com/flex/**
> macrobot-macro-commands-for-**robotlegs/<http://aaronhardy.com/flex/macrobot-macro-commands-for-robotlegs/>
Hey guys,
just wanted to add this link to the discussion as well :)
http://as3commons.org/as3-commons-async/introduction.html
as3commons-async aims to provide a common API for all sorts of asynchronous
functionality in actionscript. It would be nice if the Flex framework could
try and support a similar approach.
Right now its kind of confusing to use AsyncTokens, eventdispatchers, and
complete events for all the various types of async behaviour.
cheers,
Roland
Re: Actionscript workers and async locking?
Posted by Robert Smith <ro...@thedevprocess.com>.
Hi Cosma,
It sounds like you really can't do much about the timing of your
bootstrap if one call is dependent upon the result of your prior call.
Even if you had threads available, you'd be waiting the same amount of
time. So, I'm thinking the best you're going to get at this point is
some nice code organization that is easy to follow. Here are some
resources I've found helpful.
Cairngorm 3 Task framework -
http://sourceforge.net/adobe/cairngorm/wiki/CairngormLibraries/
PureMVC (framework dependent) -
http://trac.puremvc.org/Utility_AS3_AsyncCommand
Robotlegs (framework dependent) -
http://aaronhardy.com/flex/macrobot-macro-commands-for-robotlegs/
Cheers,
Robert
On 3/23/2012 7:19 AM, Cosma Colanicchia wrote:
> Thank you for the suggestions, in fact I wrote some classes to help
> managing a set of parallel/sequence remote invocations (e.g. lanch
> multiple methods sequentially or in parallel, and notify me with the
> results at the end).
>
> However, the problem usually arise when the next invocation is based
> on the result of the previous. In my experience, even a simple linear
> algorithm (something like "if f(x) return g(x) else return h(x)" with
> f, g and h being async operations) usually become more difficult to
> read when async operations are involved. Without worker threads, I
> understand the technical problem and accept the complexity.. with
> worker threads available, it would be difficult to justify it.
>
> I don't know in details the async chaining facilities of the framework
> you mentioned, I'm looking into them, do you have any reference to
> help me find them?
>
>
> Cosma
>
>
> 2012/3/23 Robert Smith<ro...@thedevprocess.com>:
>> eems 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.
Re: Actionscript workers and async locking?
Posted by Cosma Colanicchia <co...@gmail.com>.
Thank you for the suggestions, in fact I wrote some classes to help
managing a set of parallel/sequence remote invocations (e.g. lanch
multiple methods sequentially or in parallel, and notify me with the
results at the end).
However, the problem usually arise when the next invocation is based
on the result of the previous. In my experience, even a simple linear
algorithm (something like "if f(x) return g(x) else return h(x)" with
f, g and h being async operations) usually become more difficult to
read when async operations are involved. Without worker threads, I
understand the technical problem and accept the complexity.. with
worker threads available, it would be difficult to justify it.
I don't know in details the async chaining facilities of the framework
you mentioned, I'm looking into them, do you have any reference to
help me find them?
Cosma
2012/3/23 Robert Smith <ro...@thedevprocess.com>:
> eems 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.
Re: Actionscript workers and async locking?
Posted by Robert Smith <ro...@thedevprocess.com>.
Cosma,
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
considerably.
Robert
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
Re: Actionscript workers and async locking?
Posted by Martin Heidegger <mh...@leichtgewicht.at>.
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.
yours
Martin.
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
>
>
Re: Actionscript workers and async locking?
Posted by Left Right <ol...@gmail.com>.
I don't feel the async calls to networking API are a burden. I also have a
strong dislike of lock'ing from Java, so I don't feel particularly
enthusiastic about your example, but I can also see how this would be a
common thing to do. Think of what happens if your first call ends up in an
error? - will the lock be released? - if so, maybe the second part of the
code shouldn't be executed? Or maybe it should? and so on. Well, it is too
early to speculate about how the threading may look in AS3, but if I could
have a wish, I'd rather it be done in a way it is in Erlang, then Java
because it makes concurrency problems easier to spot / more similar to
events we already have in Flash.
If there is any improvement I wish for Flash networking API it would be
consistency. There is a handful of classes all having load() methods, but
impossible to abstract because the signature of the load() is different
(invariant types of context that is passed as a second argument). The
division of responsibilities of the said classes is lacking structure. Some
of them may be able to do the same thing, while not even being in any sort
of relationship one to another.
I'd be happy if Flash API followed more fairly the definitions of protocols
they implement and provide some sort of abstraction to that. S.t. for
example there would be an HTTP class that can connect, disconnect and
expose the stream, while connected, similarly, RTMP class etc, all either
inheriting or implementing the same superclass / interface.
I don't know what's the purpose of Flex RPC packages. So, I don't really
have an opinion on async tokens and such. That always seemed to me to be an
attempt of adding yet another layer of indirection on top of something that
already has few such layers.
Best.
Oleg