Subject: Re: [boost] [gsoc] Boost.Process done
From: Ilya Sokolov (ilyasokol_at_[hidden])
Date: 2010-09-01 10:19:57
On 01.09.2010 3:03, Boris Schaeling wrote:
> 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 obvious name for dummy is null or the like, as it redirects to/from
/dev/null, /dev/zero or NUL.
>> 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)?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk