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
