Proposal for a MessageQueue (was Re: public MessageBox)

[Sean Kelly]

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

> On Wednesday, 21 March 2012 at 03:37:35 UTC, Nathan M. Swan wrote:
>> After playing around with making a library with uses threads, I realized it would be nice if there could be multiple inter-thread mailboxes than just one per thread. That way, client code and third-party library code don't interfere with each other.
>> 
>> So this is my proposal: that std.concurrency is modified so that class MessageBox is public and MessageBoxs be passed around through other MessageBoxs, or perhaps another class is devised for this.
>> 
>> I'm not sure of the implications of this, though I know I would find it very useful by allowing me to write code without ("import core."~someLowLevelModule)
> 
> After thinking about this more, this is my proposal for the API. Backward compatibility is more important here than in other places because it is documented in TDPL.
> 
> Each Tid contains a default MessageQueue accessible by property messageQueue.
> 
> The send/receive functions and their variants operate on the tid's default messageQueue.
> 
> The interface for class MessageQueue:
> 
> void send(T...)(T vals);
> void prioritySend(T...)(T vals);
> void receive(T...)(T ops);
> receiveOnlyRet!(T) receiveOnly(T...)(T ops);
> bool receiveTimeout(T...)(Duration duration, T ops);
> @property void maxSize(size_t size);
> @property void onCrowding(OnCrowding oc);
> @property void onCrowding(bool function(MessageQueue) doThis);
> 
> Hopefully, this won't break any current code, and it will be easy to implement.

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