rick.hudson at intel.com
Mon Sep 24 06:55:03 PDT 2012
http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism and http://wiki.ecmascript.org/doku.php?id=strawman:concurrency.
The latest HotPar https://www.usenix.org/conference/hotpar12/tech-schedule/workshop-program had two interesting papers
Parallel Programming for the Web<https://www.usenix.org/conference/hotpar12/parallel-programming-web> https://www.usenix.org/conference/hotpar12/parallel-programming-web
Parallel Closures: A New Twist on an Old Idea https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea
Feedback is always appreciated.
From: es-discuss-bounces at mozilla.org [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Jussi Kalliokoski
Sent: Monday, September 24, 2012 8:44 AM
What if we introduce Function#fork(), which would call the function in another thread that shares state with the current one (how much state it shares is an open question I'd like to hear ideas about, but one possibility is that only the function arguments are shared) using a similar signature to Function#call except that the first argument would be a callback, which would have error as its first argument (if the forked function throws with the given arguments, it can be controlled) and the return value of the forked function as the second argument.
* What are the technical limitations of this?
* What are the bad/good implications of this on the language users?
* Better ideas?
I have a detailed example of showing Function#fork in action  (I was supposed to make a simplified test, but got a bit carried away and made it do "parallel" fragment shading), it uses a simple fill-in for the Function#fork using setTimeout instead of an actual thread.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss