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