Function#fork

[Jussi Kalliokoski]

Hi David,

Very nice insight, thanks. I agree with you on the shared state,
transferable ownership is a much more tempting option. Especially since
even immutable shared state is hard to achieve in JS, given we have
getters, setters and proxies, etc.

Cheers,
Jussi

On Mon, Sep 24, 2012 at 5:12 PM, 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120924/63adde7e/attachment.html>