== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > Occasionally people here ask for ways in which they can help D. One > thing that would be extremely helpful at this point would be to help > defining and implementing D's new concurrency API. Unfortunately, > Bartosz has declined to contribute. That leaves Walter, Sean, Don, and > participants to this group to do it. > I'm sure you know the three of us are overcommitted, and I'm also sure > many of you are also in that situation. But if we could somehow focus > all of the energy and good will in this group to one task of > extraordinary urgency and importance, that would be awesome. > If anyone has ideas, suggestions, and code to help defining a new > concurrency API for D, please post.
For what it's worth, I've been experimenting with message-passing for one leg of the API. I decided to copy the Erlang API because it's very simple and easy to build fancier stuff on top of. What I have so far is: 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. Also 'ops' in recvmsg are delegates. Typical use would be: // Thread A sendmsg( pid, 5 ); sendmsg( pid, tuple(5) ); // Thread B recvmsg( pid, (int val) { writefln( "got int: %s", val ); } ); recvmsg( pid, (Tuple!(int) val) { writefln( "got tuple: %s", val ); } ); I thought about using predefined types for "receive any" and "abort after timeout" functions to pass to recvmsg. Pattern matching in D is largely limited to type matching at the moment, which is kind of a limitation, so I'd considered having the delegates return a bool indicating whether the value passed was a match or not. Anyway, thought I'd just add this to the thread in case it sparks discussion. I have a working implementation of this around somewhere if anyone is interested.