Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Boris Schaeling (boris_at_[hidden])
Date: 2012-11-13 19:24:03

On Tue, 13 Nov 2012 23:42:08 +0100, Yakov Galka <ybungalobill_at_[hidden]>  
wrote:

> [...]Now, consider the following execution order: A1, B1, A2, B2, A3,  
> B3. The
> result is that the write-end of the pipe of b.exe is inherited by a.exe  
> too
> (i.e. 'leaked' into a.exe). b.exe exits, closing its write-end of the  
> pipe.
> However, a.exe still holds (indefinitely) the write-end of b's pipe!
> Result: thread B will hang until the unrelated process a.exe exits (and
> perhaps all the children that a.exe created in its own turn).

On Windows create_pipe() creates non-inheritable handles for the pipe.  
They only become inheritable when an initializer like bind_stdout is used.  
Do you think this solves the problem you outlined?

On POSIX one could use initializers like close_fds or close_fds_if to  
explicitly close file descriptors for child processes. Then no "leak"  
should be possible either.

I don't know whether that would be enough to turn Boost.Process into a  
thread-safe library (I didn't think about thread-safety yet). But then  
your example could be worth adding to the FAQ?

Boris

> [...]