Revamped concurrency API

[Sean Kelly]

== Quote from Andrei Alexandrescu (SeeWebsiteForEmail at 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.