Boost logo

Boost :

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?


Boost list run by bdawes at, gregod at, cpdaniel at, john at