dmd-concurrency

[Shammah Chancellor]

On 2013-11-23 01:46:22 +0000, Chris Williams said:

> On Friday, 22 November 2013 at 23:21:33 UTC, Shammah Chancellor wrote:
>> On 2013-11-22 23:14:44 +0000, Chris Williams said:
>> 
>> I am suggesting you define a particular type of message to be received, 
>> and then send that to the Thread/Fiber's MessageQueue.   Then the 
>> Channel is just an interface to broadcast messages to all the 
>> subscribers of a particular channel.  Then each thread need only poll 
>> one queue.
> 
> With a SingleChannel, that's not really an option. Theoretically, it 
> could choose a random subscriber with space in its MessageBox as the 
> next recipient, but there would be no guarantee that a thread which had 
> just decided to shut itself down hadn't been selected, in which case 
> the message would be lost. The channel really needs to have an internal 
> queue that all the threads look at when they call receive.
> 
> For DuplicateChannel, I could indeed go and copy the data into each 
> individual thread's box, so that it only had to check there for 
> messages during receive (if not subscribed to any SingleChannel 
> instances), but I would still need to have the logic in place to scan 
> for in-channel boxes because of SingleChannel, in which case I might as 
> well establish the presence of boxes in channels as the norm for 
> DuplicateChannel as well.
> 
> This does give us the advantage that if the user requests calls against 
> a single channel, there is no extra overhead associated with that act, 
> because it has to scan through a large list to find the appropriate 
> items. It also allows the user to customize the behavior of the 
> MessageBox on a channel-by-channel basis. Setting a "max number of 
> messages" per channel, when all messages go into the same bucket, would 
> end up wonky.

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 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.

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.

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?

It seems you want SingleChannel and DuplicateChannel not block each 
other for the same reason I don't want DuplicateChannels to block 
Task-specific receive()'s.   However, I think SingleChannels are the 
oddity here, and should be treated as such, rather than Tid.send()

-Shammah