On Friday, 22 November 2013 at 22:35:47 UTC, Shammah Chancellor
wrote:
On 2013-11-22 22:34:19 +0000, Shammah Chancellor said:
Edit, I see that you have receiveAll.. I didn't notice that.
However, that still doesn't satisfy the problem when you want
to do receive() for your Tid, and receiveAll() from your
channels.
receiveAll() could pull from the thread's personal message box as
well as all of its subscribed channels, so that it truly was a
"receive ALL".
My thoughts for reasons to avoid that, however, are:
1. Threads always have their own message box allocated - even if
it's empty - whereas with channels, at most you only have as many
message boxes as you subscribed to. So my thinking was that if
people are unlikely to mix channels-based systems and
direct-sends in the same application, then every call to
receiveAll() is having to spend an extra cycle checking the
direct-send message box.
2. Since a Channel is just an interface, the implementation of
which can vary, anyone who wanted to implement a
NetworkedDuplicateChannel() class would be able to do so and pass
it into a module that only includes std.concurency. This allows
the actual implementation of any given channel to behave
completely different from one another and quickly port code from
one type to the other. send()/receive() are just innate to
threads, however, and can't be replaced except by changing the
import in each file to something else. Knowing that and also
knowing that any direct-messaging system would probably be built
like a channel (so that it had a constructor/init function where
an IP and port could be configured, and perhaps an explicit
startListening() method to call), I don't see anyone trying to
override send()/receive() as their method for receiving direct
messages over the network. They would still use the Channel
interface, so there's not much value in trying to tie the two
together.
