Proposal for a MessageQueue (was Re: public MessageBox)

[Nathan M. Swan]

On Thursday, 22 March 2012 at 15:53:56 UTC, Sean Kelly wrote:
> I can see adapting the API so that each thread has a default 
> message queue (keep in mind that we'll be adding interprocess 
> messaging at some point via the same routines). I'm not yet 
> clear how the existence of alternate message queues could be 
> communicated to other portions of the code though. register() 
> is one way I suppose. Really what's happening here is that Tid 
> is being replaced by a queue ID, not extended with a mutable 
> variable.

I think they would be passed as parameters to spawn or received 
from the default message queue.

> I guess Tid would become an alias for the Qid created when a 
> thread is spawned. What I really don't want though, is for 
> receive() to operate on a message queue created in a different 
> thread. Messaging would become substantially slower if 
> receive() had to be synchronized.

That's a drawback I haven't considered. To solve this, it would 
be made part of the contract that receiving must all be done in 
one thread.

I can't think of a use where receiving in multiple threads would 
apply, but if it would, a SynchronizedMessageQueue subclass could 
easily be drawn up that broadens the contract and synchronizes 
for receive().

BTW, how do you unittest just the std.concurrency module?