Ted Patrick - Demos & MAX @ Adobe Systems
Note: This is the personal blog of Ted Patrick. The opinions and statements voiced here are my own.
Flash Player Feature Request - Continuation Support (Practical Threading)
DIGG IT!
3
Comments
Published
Wednesday, October 29, 2003
at
8:46 AM
.
Continuations are a simple threading model that is supported in several stack based systems. So what exactly are continuations? And how should Flash support them?\0
Continuations are special functions that never return to the stack and allow the stack to continue processing. The execution of a continuation is thus parallel to the operation of the stack. Continuations run until they complete. Most often they execute another continuation or call themselves recursively. When execution reaches the end of a continuation, the execution ends and all resources are returned / garbage collected.
In most stack based systems (Flash, Python, Java), when you call a function, stack processing moves to processing the function and returns to the next instruction after the function is executed. This forces the stack to always work under a single thread and never allows the system to process 'N' items in parallel.
Example of continuation support for ActionScript:
myContinuation = continuation(){
trace('myContinuation Executing')
//if data is true call the continuation again
if (mydata ==1){ arguments.callee() }
//if this point is reached kill the continuation
}
mydata = 1
myContinuation()
trace('hello')
mydata = 0
trace('end')
Output:
myContinuation Executing
hello
myContinuation Executing
end
Output without continuation support:
myContinuation Executing
256 levels of recursion were exceeded in one action list.
This is probably an infinite loop.
Further execution of actions has been disabled in this movie.
This would add a simple light parallel execution model to the Flash Player providing a solution to a entire host of problems:
1. Parallel instantiation - Shorten the delay in instantiating components, frameworks, etc.
2. Parallel execution of event listeners - All events would be processed at close to the same time frame, vs. sequentially.
3. Parallel events execution - Allowing player events to be processed at once independently.
4. Process XML in parallel
5. {Your reason here}
A system independent threading model is just what the Flash Player needs to escape the performance related problems of the current architecture. Even with the enhancements in v7 of the player, the V2 component model takes the player to the performance limit. This is a direct result of Flash being a stack based system without support for parallel processing.
To support this initiative please do the following:
1. Sign the comments showing your approval for Macromedia to develop this feature
2. Send this request in parallel to Macromedia Wish Form
Comments and suggestions are always welcome.
Thanks,
Ted Patrick
PowerSDK Software Corp.
3 Responses to “Flash Player Feature Request - Continuation Support (Practical Threading)”
Post a CommentWhere to find me:
Ted on Twitter - @AdobeTed
Ted on Adobe Groups
Ted on LinkedIn
Ted on Facebook
Ted at Adobe
Latest
- Help ... PowerSDK Chat Client API
- A Runtime Perspective
- Darwin 7 (OSX 10.3) updated on x86 too...
- Stored Procedures in ASR Remoting
- Flash Usability - Pop-up blockers
- Non-XML over XMLSocket for F5-F7 Players
- Houston, we have comments....
- Eolas Workaround Part 2
- Eolas Workaround
- __q_click >> Click Event Queue in FUI V2 Component...
Lists
Links
Jobs
Flex JobsArchives
- May 2003
- June 2003
- July 2003
- August 2003
- September 2003
- October 2003
- November 2003
- December 2003
- January 2004
- February 2004
- March 2004
- April 2004
- May 2004
- June 2004
- July 2004
- August 2004
- September 2004
- October 2004
- November 2004
- December 2004
- January 2005
- February 2005
- March 2005
- April 2005
- May 2005
- June 2005
- July 2005
- August 2005
- September 2005
- October 2005
- November 2005
- December 2005
- January 2006
- February 2006
- March 2006
- April 2006
- May 2006
- June 2006
- July 2006
- August 2006
- September 2006
- October 2006
- November 2006
- December 2006
- January 2007
- February 2007
- March 2007
- April 2007
- May 2007
- June 2007
- July 2007
- August 2007
- September 2007
- October 2007
- November 2007
- December 2007
- January 2008
- February 2008
- March 2008
- April 2008
- May 2008
- June 2008
- July 2008
- August 2008
- September 2008
- October 2008
- November 2008
- December 2008
- January 2009
- February 2009
- March 2009
- April 2009
- May 2009
- June 2009
- July 2009
- August 2009
- September 2009
- October 2009
- November 2009
Yes, I back you up. Continuations is a must for flash player. I can believe that web frameworks such as seem are starting to implement continuation in their multi-user environments to preserve state and emulate synchronizity and rich clients such as Flex which are obviously single user cannot yet implement that.
I completely agree - ActionScript should support coroutines in some manner - it would greatly extend the power of the single thread without getting too far into the hazards of multithreading. If I understand you, the concept you're thinking of are actually coroutines, and the approach you have in mind for supporting coroutines is like the modified generator syntax of Python 2.6. I *think* that the scheme call/cc construct typically referred to as continuations is more general, but I'd be thrilled with coroutine support via generator-like functionality (like a more flexible version of what was once proposed in the abandoned ECMAScript revision.)
Yes, I completely agree. You're thinking I believe of coroutines, and the approach you have in mind for supporting them is like the Python 2.6 extension to generators. Interesting that the abandoned ECMAScript extension included generators but ActionScript doesn't have them - it would be great if they were not only supported by also extended as with Python 2.6 to allow passing of arguments in both directions. (I think the call/cc continuations of scheme is related but more general, maybe more powerful than needed.)
Coroutines would greatly extend the power of the single thread, without going to far into the hazards of completely free-for-all multithreading. I hope their support becomes ubiquitous in the near future, including in ActionScript where they are especially relevant.