A blog post from 2007 on this topic, which you might enjoy:
http://brendaneich.com/2007/02/threads-suck/
/be
Jussi Kalliokoski wrote:
As I suspected. Glad to hear my assumptions were correct. :) I think
this is a good thing actually, we'll have a good "excuse" not to have
shared state in the language (fp yay).
For the record, I've updated my initial JS fragment shading experiment
using Workers (on which my previous example was based) to take use of
the Transferrables [1] [2]. If you compare the results on Chrome and
Firefox, the benefit of Transferrables is quite impressive.
There seems to be a small downside to Transferrables though, as I
couldn't figure out a way to send parts of an ArrayBuffer using them.
Cheers,
Jussi
[1] http://labs.avd.io/parallel-shading/test.html
[2] https://gist.github.com/2689799
On Mon, Sep 24, 2012 at 5:59 PM, Alex Russell <[email protected]
<mailto:[email protected]>> wrote:
Let me put bounds on this, then:
Approaches that enable shared mutable state are non-starters. A
"send" based-approach might work (e.g., Worker Tranferrables) as
might automatic parallelization (e.g., RiverTrail) -- but threads
and thread-like semantics aren't gonna happen. Turn-based
execution with an event loop is how JS works and anything that
changes that apparent semantic won't fly.
Regards
On Mon, Sep 24, 2012 at 3:09 PM, Jussi Kalliokoski
<[email protected] <mailto:[email protected]>>
wrote:
Hi Rick!
Thanks for the links, very interesting! I was already aware of
River Trail and other concurrency proposals for JavaScript, my
purpose for this thread was anyway to get good clarification
on what approaches are impossible and why and what approaches
are possible and what are their virtues / downsides. So thanks
again, those two papers are more than I hoped for! But I hope
that there will be more discussion about this.
Cheers,
Jussi
On Mon, Sep 24, 2012 at 4:55 PM, Hudson, Rick
<[email protected] <mailto:[email protected]>> wrote:
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]>
[mailto:[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] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
