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]> 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]>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:* [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] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
