On Tue, 31 Aug 2010 15:08:37 +0200, Jeff Flinn <TriumphSprint2000@hotmail.com> 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