Boost logo

Boost :

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)?


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