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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-09-12 11:45:38

On Sun, 12 Sep 2010 01:03:59 +0200, Jeremy Maitin-Shepard  
<jeremy_at_[hidden]> wrote:

> [...]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).

Yes, this is what create_child() does with the standard streams. And I  
agree you probably have to do the same (calling fcntl(..., F_DUPFD, 3)).  
But I'm not sure if this POSIX-only problem which can be rather easily  
solved by the user and is only an issue when a fd > 2 should be mapped to  
a fd < 3 justifies to change the interface of context (at least I don't  
expect it will become easier to use)? I would agree that this would  
definitely need to be documented. But I'm still not sure whether  
Boost.Process should provide a posix_context class which supports the  
scenario above out of the box (I can already hear users asking "if the  
library supports X on POSIX why not Y?"). If we could somehow draw a line  
between "good" and "bad" platform-specific features it will be much easier  
for maintainers later. Maybe a direct question helps: Why should  
Boost.Process support fds > 2 out of the box but not chroot for example  
(there was a string member variable in context in previous versions to  
easily set the root directory)? Or your preference is just the opposite  
and you like to see additional platform-specific classes which support as  
many platform-specific features as possible?

Boris