On Thu, 19 Aug 2010 21:17:08 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
Boris Schaeling wrote:
On Wed, 18 Aug 2010 11:23:56 +0200, Ilya Sokolov <ilyasokol@gmail.com> wrote:
[...]Now after line 3 the child process has the following fds: 0 closed 1 wend of pipe created for stdout 2 wend of pipe created for stdout (!) 3 closed Not sure why you think so? I've attached the program I used to try to reproduce the behavior but it works fine. Maybe you can update it if you think there is a problem?
Could you swap these lines?
ctx.stdout_behavior = bpb::pipe::create(bpb::pipe::output_stream); ctx.stderr_behavior = bpb::pipe::create(bpb::pipe::output_stream);
I see, very good catch! File descriptor 3 (the write end of the pipe created for stdout) is mapped to STDOUT_FILENO with dup2(). As STDOUT_FILENO is file descriptor 1 that one is automatically closed by dup2(). In this use case file descriptor 1 is unfortunately the write end of the pipe created for stderr though. Any idea how to easily fix this? As far as I see the order of mapping read/write ends to stdin, stdout and stderr depends on whether another behavior actually uses the file descriptors 0, 1 and 2. In the worst case however the write end of the pipe created for stdout is 2 and the write end of the pipe created for stderr 1. Either we put a warning in the documentation or we come up with some clever code? (In the moment I'm a bit in a hurry. If there are no proposals I'll think about it on the weekend. :) By the way, I wonder if Boost.Test likes a test case which closes all file descriptors? It would be nice if this could be added as a test case. Boris