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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-08-21 09:13:48

On Thu, 19 Aug 2010 23:58:08 +0200, Ilya Sokolov <ilyasokol_at_[hidden]>  
wrote:

> [...]
>> 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. :)
>
> Three choices that I know of:
>
> 1. Before creating any new file (such as in bpb::pipe::create()
> or bpb::dummy::create(), not sure about bpb::inherit::create()), you  
> could "occupy" fds which behavior has been set to != bpb::inherit.

Then a behavior class would somehow need to know what another behavior  
class has been doing? The constructors of the behavior classes would need  
access to the context object to check the other stream behaviors?

> 2. Create new files in the ascending order of the corresponding fds.

This would then be the responsibility of the library user (stdout_behavior  
would need to be set before stderr_behavior for example)?

> 3. Put this and other problems on the user, like in posix_spawn()
> http://www.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html

Same as above (library user's responsibility)?

>> 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.
>
> You could dup std descriptors to some upper fds before the test and dup
> them back after the test.

I will try this and hope Boost.Test doesn't use any other file  
descriptors. :-)

Boris