Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-08-25 18:13:47

On Sat, Aug 25, 2012 at 10:37 PM, Boris Schaeling <boris_at_[hidden]>wrote:

> If you want to have a certain behavior on all platforms, you only need to
> use an initializer. But if someone else doesn't care about a certain
> behavior, the library shouldn't do something no one asked for.

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,
useful one, not the the lighter on resources, until specifed otherwise.
Look at other similar examples: std::thread forces you to detach() or
join() threads before destruction, calling std::terminate() if it have not
been done: this forces the user to define the relationship between the
threads, making it very hard to "leak" a thread without doing
it explicitly. A thread instance is the unique object through which you can
manipulate one specific thread. I think it is sound design because it is
cheap behavior that still force relatively safe usage (at least far more
safe than if threads would be manipulable only by handles).

Here it seems that the most useful use case of such library should be
defined before fixing the design. Which behaviour is the safer? Which
behaviour is the most expected?
I don't have data personally as it requires research but my personal guess
is that nobody wants to :
 - loose handle on the child process when going out of scope
without explicitly detaching it from the current process
 - not release resources by default when the child process ends (this one
is not clear to me yet in this discussion)
 - allow different part of the code to implicitly manipulate a process
which handle is shared everywhere.

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?
Couldn't boost process follow the same design principles? Is there
something specific to processes that make them far different from threads,
from user code point of view I mean?

Side optional question: have there been proposals for a process library to
the standard?

Joel Lamotte