incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosma Colanicchia <cosma...@gmail.com>
Subject Re: Actionscript workers and async locking?
Date Mon, 26 Mar 2012 12:41:16 GMT
@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 <olegsivokon@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

Mime
View raw message