On 09/11/2010 03:15 PM, Boris Schaeling wrote:
On Sat, 11 Sep 2010 23:24:32 +0200, Jeremy Maitin-Shepard <jeremy@jeremyms.com> 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.