On Wed, 22 Aug 2012 21:14:25 +0200, Alexander Lamaison <awl03@doc.ic.ac.uk> wrote:
[...]I'd strongly argue that #ifdef is not the appropriate tool on the /client/ side of the library. After all the entire point of a Boost library is to abstract such details away. Certainly in the common use cases.
I'm not necessarily happy about the #ifdefs either. But I don't rule them out completely. It all depends on the alternatives. And for the most complicated use cases (cleaning up resources and waiting asynchronously for processes to exit) we don't have anything else right now? Whatever you come up with has to be at least as good as what we have right now. And if you look eg. at the example at <http://www.highscore.de/boost/process0.5/boost_process/tutorial.html#boost_process.tutorial.cleaning_up_resources> I think it will be tough to beat that one in clarity and simplicity.
[...]I'm not very familiar with POSIX processes. Is SIGCHLD required for *all* process use-cases or just more advanced ones that give you more control/introspection than Windows processes?
I think there are basically three scenarios: - You don't mess around with SIGCHLD at all: Terminated child processes must be reaped with a blocking call to wait. - You call signal(SIGCHLD, SIG_IGN): Terminated child processes are reaped automatically (by the kernel). - You set a signal handler for SIGCHLD: You still must call the blocking function wait. But if you do this in the signal handler, wait returns immediately (this is the asynchronous waiting model). As it all works differently on Windows, and as this is not only about cleaning up resources but also partly about fetching the status of the terminated child process (it is returned by wait), all of this has to be considered for a platform-independent solution and weighed against the #ifdef alternatives.
[...]Economy of what? I'm sure you don't mean performance because blanking out the environment on Windows is just a matter of passing L"\0\0" as the lpEnvironment paramteter of CreateProcessW. I'd advocate making that the default and setting the parameter to NULL if the caller passes inherit_env. That way you get the same behaviour on both platforms.
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. (Not to think about what the same behavior should actually be. One could also argue that the Windows behavior should be the default. This leads to the question how the library user will know and remember what the default is. And then there are other settings like for standard streams which I'm afraid someone wants then to have equalized next.) Boris