Boost logo

Boost :

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-08-19 16:36:15

On Thu, 19 Aug 2010 21:17:08 +0200, Ilya Sokolov <ilyasokol_at_[hidden]>

> Boris Schaeling wrote:
>> On Wed, 18 Aug 2010 11:23:56 +0200, Ilya Sokolov <ilyasokol_at_[hidden]>
>> 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.


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