[Box Backup-dev] COMMIT r476 - box/chris/general/bin/bbackupd

[Ben Summers]

On 20 Feb 2006, at 09:33, Chris Wilson wrote:

> Hi Ben,
>
>>>  - Use overlapped I/O and IPC to avoid writing to control socket  
>>> while
>>>    another thread is reading from it, which causes race  
>>> conditions and
>>>    deadlocks
>>
>> Wow. This is complex. Would using critical sections and perhaps  
>> PeekNamedPipe be less complicated? I can't believe overlapped I/O  
>> and messaging is necessary, and think we should strive for  
>> simplicity.
>>
>> I am curious as to why it's necessary.
>
> Yeah, it is pretty complex, but it wasn't too hard to write (about  
> 7 hours), amazed me by working almost perfectly first time, and I  
> think it is necessary to meet the conditions you once set out.
>
> It breaks down into 2 parts: IPC, and overlapped I/O.
>
> IPC is simply essential. We cannot call API functions on the named  
> pipe in two different threads, or the application will deadlock.  
> Read() and Write() is one example. All I/O must be done by the  
> handler thread. The safest and most obvious way to pass the  
> messages from the main thread seems to be a message queue protected  
> by a critical section and signaled by an Event.

Why can't you wait on the pipe rather than the event, and just do all  
the I/O in the main thread?

>
> Overlapped I/O may not be essential, but if you want to avoid  
> polling the command socket, as you once said to me, then it is.  
> Overlapped seems to be the only way that I can tell from the docs  
> for you to be notified that you have a message waiting to be read  
> (especially if you want to combine it with waiting for an event  
> from the main thread).

Maybe I'm wrong in thinking that you can wait on pipes.

> Otherwise you have to either poll the socket with Peek, as you  
> said, or you end up blocked in ReadFile where you can't service the  
> main thread by writing messages to the client.

Yes, blocking would be bad!

>
> By all means ask Charles to review it, or anyone else you like, but  
> I don't think it's excessively complex, and at least the IPC stuff  
> does fix some major bugs - the command socket was essentially  
> liable to deadlock the whole process before.

I'm not saying it's wrong, I'd just like to know why it's necessary.

Ben