Function#fork

[Rick Waldron]

On Mon, Sep 24, 2012 at 10:12 AM, David Bruant <bruant.d at gmail.com> 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.
>


I'd also be concerned about something like this...

/* main process */
global.foo = { value: 1 };

function computer( value ) {
  /* fork process */

  global.foo.value = value;
}

computer.fork( 20 );

// nothing is stopping me from calling like this either:
computer( 10 );





If the function that's called with .fork() tries to use references that
only exist in the main process, throw? This works in your example because
the fork() exists in the same global scope, but I can't see how it would
work for an actual new process. The solution to that problem will
immediately run into the issues that David mentioned above.


Rick






>
> David
>
> [1] http://wiki.ecmascript.org/doku.php?id=strawman:concurrency
> [2] http://wiki.ecmascript.org/doku.php?id=strawman:data_parallelism
> [3]
> http://updates.html5rocks.com/2011/12/Transferable-Objects-Lightning-Fast
> _______________________________________________
> 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/f725e6e1/attachment.html>