Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Alexander Lamaison (awl03_at_[hidden])
Date: 2012-08-22 15:14:25

"Boris Schaeling" <boris_at_[hidden]> writes:

> On Mon, 20 Aug 2012 00:53:28 +0200, Alexander Lamaison
> <awl03_at_[hidden]> wrote:
>
>> [...]I only vaguely remember the last review.  Can you remind me what the
>> problem was?
>
> The main problem was to create a class which basically does what
> boost::asio::signal_set and boost::asio::windows::object_handle
> do. These classes are very different, and if you put all their code
> into one class it's an interesting mixture of signal handling code and
> Windows wait functions. ;)

Exactly.  And right now the library /users/ are expected to be able to do
that  o_O

[...]

>> [...]Yuk.  At this point my only thought is how have others done it?
>> (It must
>> have been done before)  What about the Java or Python runtimes?  I
>> suppose they get to steal the signal all for themselves which makes
>> their job easier.
>
> I think they don't need to care much about the system level. They can
> invent a new concept Foo, and the rest is a matter of implementation
> details.

They can hardly reinvent processes.  Their runtimes must call the OS
system calls at some point and handle all the issues we are discussing
here.  The big advantage I can see that they have is that they don't
need to play nicely with other libraries.  They have the sandpit all to
themselves and can steal the POSIC signals.  Although, maybe Python
doesn't do that because 3rd party C plugins are so common.  I'm afraid I
don't have the time to check right now.

> But I'm not sure whether this is the way to go for a Boost
> C++ library? What I've been trying to do in Boost.Process 0.5 is
> making existing cross-platform concepts platform-independent in
> code. I didn't try to invent new concepts. So where I didn't find
> cross-platform concepts I accepted the fact that platforms are
> different and used the appropriate C++ tool to express the difference:
> #ifdef.

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.

> Maybe someone has a great idea how to make SIGCHLD and Windows wait
> functions platform-independent. I gave it a shot once, and it was
> rather messy. Maybe it's not a SIGCHLD vs. Windows wait function
> problem either but must be solved on a very different level. I don't
> know. I think that's a task and maybe even a library of its own. It
> took me already half a year to create windows::object_handle after the
> status class in Boost.Process 0.4 was rejected. I don't know how long
> it will take to solve the SIGCHLD/Windows wait function problem. And
> this is not the first time that it is discussed on the mailing list
> (only six years since the very first Boost.Process draft ;).

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?

>> [...]My criticism wasn't directed at any lack of initialisers, just
>> that the
>> default behaviour of the two platforms varied when the library could
>> make it match, either favouring the POSIX way of inheriting nothing by
>> default or the Windows way of inheriting everything.
>
> Ah, I see. Well, I think I prefer the Law of Economy: If I don't need
> something, I don't add it. Here it means undefined behavior if you
> don't use an initializer for environment variables. But if you don't
> care about environment variables, that's fine and there is no need to
> do something extra in the library.

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.

Alex

--
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)