Besides web workers there are two straw man proposals that address adding 
parallelism and concurrency to JavaScript.

http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism and 
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency.

The Parallel JavaScript (River Trail) proposal has a prototype implementation 
available at https://github.com/rivertrail/rivertrail/wiki. You should be able 
to implement your example's functionality using this API.

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
and
Parallel Closures: A New Twist on an Old Idea 
https://www.usenix.org/conference/hotpar12/parallel-closures-new-twist-old-idea

These projects each address some important part of the general problem of 
adding parallelism and concurrency to JavaScript.

Feedback is always appreciated.


-        Rick



From: [email protected] [mailto:[email protected]] On 
Behalf Of Jussi Kalliokoski
Sent: Monday, September 24, 2012 8:44 AM
To: es-discuss
Subject: Function#fork

Hello everyone,

I've been thinking a lot about parallel processing in the context of 
JavaScript, and this is really a hard problem. I'm very curious to hear what 
everyone's opinions are about it's problems and so forth, but I don't think an 
open question like that will give very interesting results, so I have an 
example problem for discussion (while it seems like a bad idea to me, and 
unlikely to ever get to the language, what I want to know is everyone's 
reasoning behind their opinions whether it's for or against).

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?
 * etc.

I have a detailed example of showing Function#fork in action [1] (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.

Cheers,
Jussi

[1] https://gist.github.com/3775697
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to