Function#fork
Brendan Eich
brendan at mozilla.org
Mon Sep 24 12:45:59 PDT 2012
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 <slightlyoff at google.com
> <mailto:slightlyoff at google.com>> 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
> <jussi.kalliokoski at gmail.com <mailto:jussi.kalliokoski at gmail.com>>
> 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
> <rick.hudson at intel.com <mailto:rick.hudson at intel.com>> 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:*es-discuss-bounces at mozilla.org
> <mailto:es-discuss-bounces at mozilla.org>
> [mailto: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
> *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
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
More information about the es-discuss
mailing list