dmd-concurrency

[Chris Williams]

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.