Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-11 19:03:59

On 09/11/2010 03:15 PM, Boris Schaeling wrote:
> On Sat, 11 Sep 2010 23:24:32 +0200, Jeremy Maitin-Shepard
> <jeremy_at_[hidden]> wrote:
>
>> On 09/11/2010 01:51 PM, Jeremy Maitin-Shepard wrote:
>>> On 09/11/2010 01:32 PM, Boris Schaeling wrote:
>>> [snip]
>>
>>>> Please have a look at
>>>> <http://svn.boost.org/svn/boost/sandbox/SOC/2010/process/libs/process/example/file_descriptors_setup.cpp>.
>>>>
>>>>
>> [...]By the way, the example is quite possibly not even correct,
>> because file descriptors 3 and 4 might already be in use, and
>> therefore depending on the order of operations (and the relative order
>> of context::setup and boost process's internal file descriptor setup)
>> the code may do the
>
> You are right. If I remember correctly the example isn't tested yet (it
> was converted from an example from a previous Boost.Process version).
>
>> wrong thing. That is why all of the file descriptor setup has to be
>> coordinated, and therefore why boost process needs to provide an
>> interface for doing it.
>
> The interface is context::setup(). The method is called after fork() and
> before execve() in the child process only (on POSIX). When
> context::setup() is called (only) the standard streams have been
> configured and you can do whatever you like with file descriptors
> inherited from the parent process.

The fact that the example is wrong is precisely why this interface isn't 
sufficient.  To fix it, you'd have to do some careful dup gymnastics, 
all the while checking the return codes of all of the API calls and 
signaling an error to the parent process somehow.  (Not only do you have 
to check the return codes, you also have to loop and retry if you 
receive EINTR.)  Not having to bother with all of these annoyances is a 
primary motivation for using a library like Boost.Process in the first 
place.

Suppose you want to map the child's file descriptor 3 to what the 
parent's file descriptor 1 is, and you also want the child's file 
descriptor 1 to be set to something else.  You configure the child's 
file descriptor 1 using the library's interface.  Since context::setup 
is called after the child's file descriptor 1 has been remapped, you no 
longer have access to the parent's file descriptor 1, unless you took 
care to dup it previously (and ensure that you are returned something > 
2).  The library has to handle of this complexity for the standard 
streams, so I'd like it to deal with it for any other file descriptors also.