Thread overview | ||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 21, 2012 public MessageBox | ||||
---|---|---|---|---|
| ||||
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) |
March 21, 2012 Re: public MessageBox | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | 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.
|
March 22, 2012 Re: public MessageBox | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean Kelly | 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. (A+ as the grade, not the array programming language ;) ) NMS |
March 22, 2012 Re: public MessageBox | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | On Mar 21, 2012, at 5:30 PM, "Nathan M. Swan" <nathanmswan@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.
|
March 22, 2012 Proposal for a MessageQueue (was Re: public MessageBox) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | 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.
|
March 22, 2012 Re: Proposal for a MessageQueue (was Re: public MessageBox) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | Am 22.03.2012 05:12, schrieb Nathan M. Swan:
> On Wednesday, 21 March 2012 at 03:37:35 UTC, Nathan M. Swan wrote:
> Each Tid contains a default MessageQueue accessible by property
> messageQueue.
how is queued runned - another thread, or can i only communicate to the tid-thread by using the queue? if its another - don't we just double the amount of used thread - what is not a very good idea
|
March 22, 2012 Re: Proposal for a MessageQueue (was Re: public MessageBox) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | Making such interface public would even allow to integrate D communication mechanisms between processes/machines, similar to what Akka allows. "Nathan M. Swan" wrote in message news:ladihiaieksszjodfbyn@forum.dlang.org... 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. |
March 22, 2012 Re: public MessageBox | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | Le 21/03/2012 04:37, Nathan M. Swan a écrit :
> 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 will, even with different boxes.
|
March 22, 2012 Re: public MessageBox | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nathan M. Swan | On Thursday, 22 March 2012 at 00:30:51 UTC, Nathan M. Swan wrote:
> 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.
Nice to hear that I'm not alone with that opinion – I hit the same problem when implementing a request log file writer for Thrift, which runs in a separate thread and communicates with the main thread via a message queue.
It works great and performed even better than a similar C++ version due to lower lock contention, but the user'd better not try to call receiveOnly!() from »his« thread…
David
|
Copyright © 1999-2021 by the D Language Foundation