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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-08-31 19:03:12

On Tue, 31 Aug 2010 15:08:37 +0200, Jeff Flinn  
<TriumphSprint2000_at_[hidden]> wrote:

> [...]I initially tried using the provided dummy behavior, which is a  
> misnomer since it actually created temporary files and streams. I was an  
> unhandled win32 exception when shutting down.

What name would you prefer (instead of dummy)?

> The funny thing is there is already a context::setup method that would -  
> at least on windows - allow the stream behavior to be fully  
> encapsulated. A context could set the handle members of STARTUPINFOA  
> only instantiating those boost::process::behavior::streams that are  
> needed. On posix, setup could do all of the dup'ing of filenumbers, as  
> it's called between fork and execve already.

I'm not sure if I understand correctly: If setup() is required to setup  
the STARTUPINFOA structure on Windows and to duplicate or close file  
descriptors on POSIX why using a library at all? Actually create_child()  
and stream behaviors do all of this - why would you want to do this  
yourself in setup()? If the only problem is that DuplicateHandle() must  
not be called in Windows applications we could change the standard  
constructor of context. In fact in previous Boost.Process drafts standard  
streams were not inherited but closed - but then POSIX developers complain  
again as they expect inheritance. Wolfgang proposed to add another  
constructor. In order to avoid that Windows applications accidentally use  
the default constructor we could also provide only one constructor with  
three required parameters to set stream behaviors? Or another idea:  
Boost.Process does whatever developers expect on a platform (inherit on  
POSIX, nothing on Windows)?

Boris