Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Boris Schaeling (boris_at_[hidden])
Date: 2012-08-26 19:07:26

On Sun, 26 Aug 2012 00:13:47 +0200, Klaim - Joël Lamotte  
<mjklaim_at_[hidden]> 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