brendan at mozilla.org
Mon Sep 24 12:45:59 PDT 2012
A blog post from 2007 on this topic, which you might enjoy:
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  . 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.
>  http://labs.avd.io/parallel-shading/test.html
>  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.
> On Mon, Sep 24, 2012 at 3:09 PM, Jussi Kalliokoski
> <jussi.kalliokoski at gmail.com <mailto:jussi.kalliokoski at gmail.com>>
> Hi Rick!
> Thanks for the links, very interesting! I was already aware of
> 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.
> 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
> 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
> had two interesting papers
> Parallel Programming for the Web
> *Parallel Closures: A New Twist on an Old Idea
> These projects each address some important part of the
> general problem of adding parallelism and concurrency to
> Feedback is always appreciated.
> *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
> 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  (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.
>  https://gist.github.com/3775697
> es-discuss mailing list
> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss