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.
