dmd-concurrency

[Shammah Chancellor]

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