Function#fork

[Alex Russell]

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> 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>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-programhad 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] *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
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120924/320c7485/attachment-0001.html>