On Sun, 12 Sep 2010 01:03:59 +0200, Jeremy Maitin-Shepard <jeremy@jeremyms.com> 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