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

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]>  
wrote:

> 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.

Boris