Function#fork

[Jussi Kalliokoski]

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>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> 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/fc04198f/attachment-0001.html>