On Mon, Sep 24, 2012 at 10:12 AM, David Bruant <[email protected]> wrote:
> Le 24/09/2012 14:43, Jussi Kalliokoski a écrit : > > 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). > The concurrency strawman [1] defines a concurrency as well as > parallelism model. So far, it's been expressed as the favorite model for > general purpose parallelism. > Different use cases are efficiently solved by different forms of > parallelism, for instance, there is another strawman on data parallelism > [2] for the case of applying the same computation to a large amount of > data. > > > What if we introduce Function#fork(), which would call the function in > > another thread that shares state with the current one. > Shared state (no matter how much) always has the same story. 2 > computations units want to access the shared state concurrently, but for > the sake of the shared state integrity, they can't access the state > simultaenously. So we need to define a form of mutex (for "MUTual > EXclusion") for a computation unit to express the intention to use the > state that should be used by one computation unit at once. With mutexes > as we know them, used at scale, you end up with deadlocks which are > nasty bugs to find out and debug. > This is all a consequence of the idea of shared state. > > Of all this story, 2 parts can be attacked to fix the problem. Either, > define something better than what we know of mutexes (I have no idea of > what it would look like, but that's an interesting idea) or get rid of > shared state. > The current concurrency strawman is doing the latter. > > One annoying thing of naive no-shared-state systems as we know them is > that everything has to be copied from a computation unit to another. > That's not exactly true though. It's always possible to implement a > copy-on-right mechanism. > Another idea is to define ownership over data. HTML5 defines > "transferable" objects [3] which can be passed back and forth form > worker to worker but can always be used in one worker at a time. Rust > has a concept of "unique pointer" which is the same idea. > Another idea would be to have data structures which live in 2 or more > computation units, showing just an interface to each and which integrity > would be taken care of under the hood by the "VM" and not client code. > This is what local storage does for instance. > > I will fight very hard against the idea of shared state, because there > are very few benefits against all what it costs in large-scale programs. > s/shared state/shared *mutable* state/ You left out perhaps the most interesting option: persistent immutable data structures. Some implementations already exist in user land but in order to really get the concurrency win I suspect we'd probably need vm support. Interestingly, IIRC all modern js vms already bake in a form of persistent data structure with ropes -- it's not too much of a stretch to imagine similarly immutable collection APIs. (And just to be clear: immutable here does not mean an expensive CoW to "modify" -- with structural sharing these operations can be far cheaper.)
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
