View mode: basic / threaded / horizontal-split · Log in · Help
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
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
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
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)
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)
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)
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
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
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
March 22, 2012
Re: public MessageBox
On Thursday, 22 March 2012 at 15:14:31 UTC, deadalnix wrote:
> They will, even with different boxes.

Similarly succinct: How so?
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home