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
