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
