Microsoft concurrency work

[Vlad Dumitrescu]

Hi,

> From: Sean Hinde
> One thing that struck me is that they effectively have a 
> receive construct which says:
> 
> receive
>      {Ref1, Msg1} and {Ref2, Msg2} ->
>          do_code_only_when_both_arrived();
>      Other ->
>          handle_other_message()
> end
> 
> I know we can build this in Erlang, but not without some 
> faffing to track what has already arrived.

Actually, they can even synchronize on messages in different mailboxes,
which works fine because mailboxes aren't processes (in the Erlang sense).
Powerful, but IMHO creating more problems than solving (at least when
comparing to Erlang :-).

Except for the fact that their handlers are dynamic (which we don't have),
this type of handlers could be simulated by  something like 
	Pid = spawn(fun() -> 
		receive
   	   		{Ref1, Msg1} -> 
				receive {Ref2, Msg2} ->
          				do_code_only_when_both_arrived()
				end
	   	end),
	receive 
   	   {Ref1, Msg1} -> Pid ! {Ref1, Msg1};
   	   {Ref2, Msg2} -> Pid ! {Ref2, Msg2};
		Other ->
			...
	end,
Which actually could work even for Msg1 and Msg2 coming from different
processes (the problem being how to let them know the value of Pid).


Also, I wonder how easy it is to keep track of all handlers that are
installed on a single port at any moment in time. How am I supposed to
choose the proper match predicate if I don't know what other predicates are
active on that port? If I don't get a message that I expect, is it because
it didn't arrive at all, or because some other handler ate it up? *brrr* a
nightmare to debug...

Comparing to a receive statement, where all cases are explicit, I think my
bias is clear ;-)

Alternatively, I might have misunderstood everything completely. ;-)

Regards,
Vlad