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

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

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>.
>>
>> There are two pipes used to create file descriptors 3 and 4 which should
>> be inherited by the child process. As the pipe stream behavior is used
>> explicitly the user knows if 3 and 4 should be read or write ends of the
>> pipe. The user can pass the information to the pipe stream behavior
>> while the context indeed can't (in this example there is still a boolean
>> value used).
>
> I saw that example, but it hardly seemed like a very good exposition of
> the convenience provided by the library. (Also, as I alluded to in some
> of my other example code snippets and as has been discussed a bit by
> others, I think that using an std::pair as the return value for those
> type of things is a bad idea. Instead, read_end and write_end, or
> parent_end and child_end, depending on the situation, should be used.)

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 
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.