Proposal for a MessageQueue (was Re: public MessageBox)

[Sean Kelly]

On Mar 22, 2012, at 12:06 PM, "Nathan M. Swan" <nathanmswan at gmail.com> wrote:

> 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.

But will either of those solve the problem you outlined where user code is calling receiveOnly and bumping into a message meant for a third-party API?  If the API is spawning threads they typically won't be running user code, or at least would certainly impose restrictions on message queue use by called user code. And in the case of sending the Qid to the default queue, you end up with a race condition where user code might call receiveOnly. 

>> 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?

Not easily, since a failure often means that a thread hangs.