Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-10-31 19:15:29

On 28/10/2016 07:33, Klemens Morgenstern wrote:
>> 6. It is a *very* serious design flaw that i/o deadlocks if you try
>> to read after the child exits. The documentation suggests this is
>> because maybe because we are redirecting to a file. This is not a
>> good reason to have i/o deadlocking seeing as every system I've ever
>> used it is possible to configure the pipes to error if you try to
>> read from a closed pipe. The default should be to always error on a
>> closed pipe read, and if the user is foolish enough to redirect to a
>> file then it's on them to work around it rather than forcing very
>> unhelpful and bug inducing behaviour on every user.
>
> That is not the reason. In order to use boost.asio with pipes, you need
> to use named pipes on windows, which behave like file-handles. Therefore
> (afaik) the pipe does not get closed automatically, hence I cannot
> guarantee that a pipe will be closed automatically. The deadlock is
> caused for that reason: the pipe is still open, but no one is writing
> into it.

+1 for deadlock on read from exited process being a non-starter.
(The only acceptable deadlock is for obviously silly user code, eg. 
synchronous blocking on reading the child's stdout without providing 
sufficient stdin to it.  But trying to read stdout after the child has 
closed is not one of those cases.)

I don't really understand your explanation.  File handles do get closed 
automatically on process exit, so as long as the child process is the 
only one that has the write-end of the pipe open, then the read-end 
should be guaranteed to EOF when the child exits on all platforms.

If the pipe handles are being inherited by the child process (as with 
fork, or explicit in CreateProcess) then you should set parent-only 
handles to be non-inheritable prior to forking and close child-only 
handles in the parent immediately after forking.

Also, you shouldn't have to use named pipes.  CreatePipe will create 
anonymous pipes, which are just handles, and ASIO supports read/write 
operations on arbitrary handles just fine.  For launching child 
processes this should be strongly preferred over named pipes.