Revamped concurrency API

[Jeremie Pelletier]

Andrei Alexandrescu wrote:
> MIURA Masahiro wrote:
>> Sean Kelly wrote:
>>> void sendmsg(T)( Pid pid, T val );
>>> final void recvmsg(T...)( Pid pid, T ops );
>>> Pid spawn(T)( T fun );
>>>
>>> spawn() is pretty limited so far in that it only spawns threads--I'd
>>> expect that function to end up with multiple overloads at some point.
>> Interesting.  Future spawn() may spawn the thread in a remote CPU that
>> doesn't share the memory.  In that case it perhaps helps to limit fun to
>> be pure, and val to be immutable, as in Erlang.  D already has pure and
>> transitive const, so the first few steps for the massively-parallel
>> D programs are already completed! :-)
> 
> That's the plan, except that we weren't thinking of creating remote
> processes, only sending messages across process and machine boundaries.
> Here's where notions like value vs. reference and deep cloning become
> very important.
> 
> 
> Andrei

With the popularity of cloud computing today and applications pushing
toward a client frontend to a server backend, it would only be logical
to access server threads from clients.

I can see many uses of such a model, for example a cloud IDE that reads
from and saves to a specialized version control server, showing what
other devs are working on in realtime and being notified instantly of
their changes, just like google docs do.

That's why I keep saying we need multiple concurrent models in D, there
are many usages to every single one of them, and if they can all live
together its even better.

Jeremie