[dmd-concurrency] Shutdown protocol

[Andrei Alexandrescu]

Michel Fortin wrote:
> Le 2010-01-20 à 18:54, Andrei Alexandrescu a écrit :
> 
>> Not at all. On the contrary, it's the stark opposite of a race:
>>
>> * Readers only finish after they have sent all messages they had to send.
>>
>> * Application doesn't shutdown until all sent messages have been acted upon.
>>
>> It's actually remarkably clean how the two-files copy program shuts down.
>>
>> I'd agree with you it would be a race condition if readers were not waited upon. Then the amount of data written would depend on various delays in the system. But that's a horrible application design, not a horrible framework.
> 
> You can easily transform the file copy program to add the race condition though. The file copy example has one reading and one writing thread. Now let's add a processing thread in the middle that does something to the data (could be compression or encryption):
> 
> 	reading -> processing -> writing
> 
> Once the reading thread has finished, some parts will be in the process of being processed, other parts will be in the process of being written. Now, assume writing is faster than processing: the writing thread will finish what it has and wait for new messages (those parts the processing thread is still processing), but at that moment it will be interrupted by a shutdown. After that, while the processing thread slowly advance with its processing it sends messages to a dead writing thread.

I have no doubt many racy scenarios exist out there. In fact any given 
shutdown protocol is more likely to be racy than not. That's why the 
fact that there are actually non-racy applications that are easy to 
write and understand is remarkable.

About your example: in such a pipeline, I'd definitely define a simple 
protocol to signal termination, for example by sending an empty buffer 
and waiting for an ack in the reader.

That's actually a great example for the book!

Andrei