dmd-concurrency

[Shammah Chancellor]

On 2013-11-22 23:14:44 +0000, Chris Williams said:

> 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.

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.