public MessageBox

Sean Kelly sean at invisibleduck.org
Wed Mar 21 19:04:57 PDT 2012


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

> On Wednesday, 21 March 2012 at 19:53:55 UTC, Sean Kelly wrote:
>> On Mar 20, 2012, at 8:37 PM, 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.
>> 
>> They shouldn't interfere anyway.  The third-party code just has to devise a message format that client code won't look for.  Though if the client discards messages arbitrarily via receive((Variant v) {}) then all bets are off.
> 
> What about this pseudocode?
> 
> Thread1:
>    spawn Thread2
>    library sends LibMsg
>    client sends ClientMsg
> 
> Thread2:
>    client receives ClientMsg
>    library receives LibMsg
> 
> The client will receiveOnly!ClientMsg() and get a MessageMismatch.
> 
> With multiple MessageBoxes:
> 
> Thread1:
>    clientmail = new MessageBox
>    spawn Thread2(libobj, clientmail)
>    libobj.mb.send(LibMsg)
>    cleintmail.send(ClientMsg)
> 
> Thread2:
>    clientmail.receive(ClientMsg)
>    libobj.mb.send(LibMsg)
> 
> If you scroll down to the section commented out as "doesn't work", it would work if my implementation could use MessageBoxes:
> 
> https://github.com/carlor/dcaflib/blob/master/buggy/asyncobj.d
> 
> As I posted a while back, the concept of a variant message queue is wonderful and powerful, and the implementation is great. But the fact that you can't declare "auto mq = new MessageQueue()" is a gaping whole in an otherwise A+ API.

Oops you're right. I tend to forget about receiveOnly. 


More information about the Digitalmars-d mailing list