On Saturday, 23 November 2013 at 04:18:47 UTC, Shammah Chancellor wrote:
> In my uses of channels, I have not found customizing the message box size per channel to be useful.  It may be, but it's not something I want.

I agree that I have not found box size configuration to be a significant gain. Being able to configure crowding behavior is probably more useful, but there's currently nothing about those that would require more than one message box per thread. (And I could envision adding a "force in" on-crowding behavior that pops from the head and inserts into the tail, but I think I could implement that in a reasonable method, even with a shared message box.)

> I sitll think duplicate channels should behave the way I described.   Take IRC for example, where I am sending messages to other users, but also to channels which then broadcast.   I want my clients to be able to simply receive() and get messages that were intended for them specifically, or were broadcast.  I don't want to implement complex logic in order to avoid my thread hanging while trying to read from a channel if I have messages available that are specific to my thread.

I'm actually pretty easy on this topic. This was the one reason I thought of to try and merge the two systems, but shied away for the previously stated reasons.

> With regards to SingleChannel,  picking a random thread would be bad for a plethora of reasons, so I agree here.  I think we should continue to disucss this issue.  There may be some way to get Tid.receive() to behave the expected way when subscribed to SingleChannels.

What I would probably do, by removing receiveAll() and instead making receive() grab everything, is expose some methods that allow one to either insert directly into a thread's message box from a channel or register the channel as something which contains its own MessageBox that needs to be checked during a receive().

This way, a call to receive() will by default just check the thread's MessageBox, and only in special cases attempt to do something more extravagant. The overhead for a simple check like this is reasonably low that I wouldn't be concerned about adding it.

> Also, SingleChannels seem somewhat strange in general to me though -- What is the expected behavior when multiple threads receive different types of mesages from the MessageBox?  Does it consume messages it doesn't understand until it finds one it does?  This would prevent other tasks which do understand them from processing.   What is the use case for SingleChannel that a simple synchronized Queue does not acheive?

I'd say that the main difference between using channels or using a synchronized queue are:

1. Developer preference. If you like the actor model, everything looks like a nail.

2. Abstraction. My SingleChannel could, for example, be sitting on top of something like Amazon's Simple Queue Service (a data queue that's maintained on one of their servers, which can have items removed by any number of clients). I could set up a thread that polls the SQS, pulls an item off, and adds it to a synchronized queue, but I might want to write a library that translates a request to receive() as a synchronous request, from that thread, to the SQS server. With the queue model, the library would always have to have its own polling thread. With the channel model, either implementation is possible.

3. Multiple entry points. receive() is currently able to directly jump to a handler based on the message type. With a queue, I have to make everything into a generic Object (or Variant), then perform type checks to decide what to do. std.concurrency already does all of that, so it's a waste to have to rewrite the same sort of handling.

4. Multiple inputs. With the ability to register to multiple data sources, using a queue, I have to figure out my own logic for how to cycle through my list of sources, so that they're getting checked evenly. With the channel system, that is all contained for me. I can call register() on 30 different pipes, and not need to have to know how the data is being locked, scanned for types I support, nor unpackaged for use. It's all just magical, upon calling receive().

On 2013-11-25 21:48:09 +0000, Chris Williams said:

> On Saturday, 23 November 2013 at 04:18:47 UTC, Shammah Chancellor wrote:
>> In my uses of channels, I have not found customizing the message box size per channel to be useful.  It may be, but it's not something I want.
> 
> I agree that I have not found box size configuration to be a significant gain. Being able to configure crowding behavior is probably more useful, but there's currently nothing about those that would require more than one message box per thread. (And I could envision adding a "force in" on-crowding behavior that pops from the head and inserts into the tail, but I think I could implement that in a reasonable method, even with a shared message box.)
> 
>> I sitll think duplicate channels should behave the way I described.   Take IRC for example, where I am sending messages to other users, but also to channels which then broadcast.   I want my clients to be able to simply receive() and get messages that were intended for them specifically, or were broadcast.  I don't want to implement complex logic in order to avoid my thread hanging while trying to read from a channel if I have messages available that are specific to my thread.
> 
> I'm actually pretty easy on this topic. This was the one reason I thought of to try and merge the two systems, but shied away for the previously stated reasons.
> 
>> With regards to SingleChannel,  picking a random thread would be bad for a plethora of reasons, so I agree here.  I think we should continue to disucss this issue.  There may be some way to get Tid.receive() to behave the expected way when subscribed to SingleChannels.
> 
> What I would probably do, by removing receiveAll() and instead making receive() grab everything, is expose some methods that allow one to either insert directly into a thread's message box from a channel or register the channel as something which contains its own MessageBox that needs to be checked during a receive().
> 
> This way, a call to receive() will by default just check the thread's MessageBox, and only in special cases attempt to do something more extravagant. The overhead for a simple check like this is reasonably low that I wouldn't be concerned about adding it.
> 
>> Also, SingleChannels seem somewhat strange in general to me though -- What is the expected behavior when multiple threads receive different types of mesages from the MessageBox?  Does it consume messages it doesn't understand until it finds one it does?  This would prevent other tasks which do understand them from processing.   What is the use case for SingleChannel that a simple synchronized Queue does not acheive?
> 
> I'd say that the main difference between using channels or using a synchronized queue are:
> 
> 1. Developer preference. If you like the actor model, everything looks like a nail.
> 
> 2. Abstraction. My SingleChannel could, for example, be sitting on top of something like Amazon's Simple Queue Service (a data queue that's maintained on one of their servers, which can have items removed by any number of clients). I could set up a thread that polls the SQS, pulls an item off, and adds it to a synchronized queue, but I might want to write a library that translates a request to receive() as a synchronous request, from that thread, to the SQS server. With the queue model, the library would always have to have its own polling thread. With the channel model, either implementation is possible.
> 
> 3. Multiple entry points. receive() is currently able to directly jump to a handler based on the message type. With a queue, I have to make everything into a generic Object (or Variant), then perform type checks to decide what to do. std.concurrency already does all of that, so it's a waste to have to rewrite the same sort of handling.
> 
> 4. Multiple inputs. With the ability to register to multiple data sources, using a queue, I have to figure out my own logic for how to cycle through my list of sources, so that they're getting checked evenly. With the channel system, that is all contained for me. I can call register() on 30 different pipes, and not need to have to know how the data is being locked, scanned for types I support, nor unpackaged for use. It's all just magical, upon calling receive().


What about a compromise?   Extending MessageQueue to accept subscribe to a SingleChannel/etc would be useful.  I think though, that DuplicateChannels should just poke the Tid's mbox though.

Thank you for working on this.   I think it's a great initiative.    Also, can you get sending immutable messages working while you're at it? *chortle*

-Shammah

On Tuesday, 26 November 2013 at 12:02:18 UTC, Shammah Chancellor wrote:
> Thank you for working on this.   I think it's a great initiative.    Also, can you get sending immutable messages working while you're at it? *chortle*

This?

http://d.puremagic.com/issues/show_bug.cgi?id=4566

On 2013-11-26 20:01:58 +0000, Chris Williams said:

> On Tuesday, 26 November 2013 at 12:02:18 UTC, Shammah Chancellor wrote:
>> Thank you for working on this.   I think it's a great initiative.    Also, can you get sending immutable messages working while you're at it? *chortle*
> 
> This?
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=4566

Nope:

http://d.puremagic.com/issues/show_bug.cgi?id=5538

On Wednesday, 27 November 2013 at 17:42:47 UTC, Shammah Chancellor wrote:
> On 2013-11-26 20:01:58 +0000, Chris Williams said:
>
>> On Tuesday, 26 November 2013 at 12:02:18 UTC, Shammah Chancellor wrote:
>>> Thank you for working on this.   I think it's a great initiative.    Also, can you get sending immutable messages working while you're at it? *chortle*
>> 
>> This?
>> 
>> http://d.puremagic.com/issues/show_bug.cgi?id=4566
>
> Nope:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5538

Maybe I'll set that as my first task, to familiarize myself with all of the templating and variant nonsense that's being used in the module, before adding anything new.

I'll try this weekend and see where I get.