dmd-concurrency

Chris Williams yoreanon-chrisw at yahoo.co.jp
Fri Nov 22 17:46:22 PST 2013


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.


More information about the Digitalmars-d mailing list