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.
Creating remote threads (maybe not OS-level processes) is certainly possible, and I wouldn't be surprised if we did that at some point, assuming something like spawn() is added. But this would be largely invisible at an API level. Like Andrei, I'm more interested in exploring what types should be allowed within messages, what language and library features are necessary, etc. Restricting messages to only shallow value types is certainly possible, but it's rather limiting. I've also experimented with ways to wrap a "shared" container in the same sendmsg/recvmsg interface, but haven't decided if it's an idea worth pursuing yet (or whether it can even be done in a sufficiently robust manner). In any case, that seemed like one way to eliminate obvious use of mutexes for accessing shared data.
