On Sun, 26 Aug 2012 00:13:47 +0200, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
[...]I can't agree on this because I think the terms are misleading. The library is supposed to provide safe and and useful (and correct) behaviour as a priority - as far as I understand boost libraries. It is no about "something no one asked for". The minimal behaviour should be the safe,
I was only referring to the environment initializer here where it's just a matter of preference what the default behavior should be? The RAII issue is indeed a different one where I agree that safe and correct behavior is very much desired.
[...]And I think that's why std::thread was designed that way. So my question is: have previous versions of boost.process been designed following the same principles than boost.thread (I suppose it had at some point?) and why did it fail?
I had a look at version 0.4. We did have a handle type there which would close a file descriptor or Windows HANDLE automatically (kind of specialized shared_ptr). On Windows this RAII type would reliably close the process handle when child went out of scope. Interestingly, I don't find any reference in the entire documentation to what to do on POSIX. I don't remember whether we forgot or expected users on POSIX to always fetch the status (or we knew we can avoid a long discussion on the mailing list if we don't mention anything in the documentation ;). I had another look at <http://www.highscore.de/cpp/process/> which is about version 0.31. There I found this: "[...] it is recommended to always reap child processes by calling wait()." Anyway, let me ask now a few questions: - Would you prefer if child would close the process handle on Windows in its destructor automatically? - Would that be still OK given that it doesn't help at all on POSIX? - Could such a type trick library users into thinking their code is safe and correct on all platforms while in fact they must do something extra on POSIX to avoid zombies? I guess it would be interesting if others answer these questions, too.
[...]Side optional question: have there been proposals for a process library to the standard?
Not that I know. Boris