On Sat, Aug 25, 2012 at 10:37 PM, Boris Schaeling <boris@highscore.de>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