Jump to page: 1 2 3
Thread overview
public MessageBox
Mar 21, 2012
Nathan M. Swan
Mar 21, 2012
Sean Kelly
Mar 22, 2012
Nathan M. Swan
Mar 22, 2012
Sean Kelly
Mar 22, 2012
David Nadlinger
Mar 22, 2012
Sean Kelly
Proposal for a MessageQueue (was Re: public MessageBox)
Mar 22, 2012
Nathan M. Swan
Mar 22, 2012
dennis luehring
Mar 22, 2012
Paulo Pinto
Mar 22, 2012
Sean Kelly
Mar 22, 2012
Nathan M. Swan
Mar 22, 2012
Sean Kelly
Mar 22, 2012
Nathan M. Swan
Mar 23, 2012
Sean Kelly
Mar 23, 2012
Nathan M. Swan
Mar 23, 2012
David Nadlinger
Mar 23, 2012
Nathan M. Swan
Mar 23, 2012
Dmitry Olshansky
Mar 23, 2012
Sean Kelly
Mar 22, 2012
deadalnix
Mar 22, 2012
David Nadlinger
Mar 22, 2012
deadalnix
March 21, 2012
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
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
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
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
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
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
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
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
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
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