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-19 06:46:12

On Sun, Aug 19, 2012 at 12:12 PM, Boris Schaeling <boris_at_[hidden]>wrote:

>
> Maybe the name child is a bit misleading. It should really be a PID
> (POSIX) and process and thread handle (Windows) only. And as you can copy
> PIDs and handles as much as you want (and no one has a problem with those
> being copyable), child should work the same. From this point of view, I
> think boost::noncopyable would be an overkill.
>

I cannot agree with this argument: whatever the implementation, child still
represent the only way to manipulate the child process. It's interface
should be thought from the point of view of the user, not only the
implementation.
Making it non-copyable (but movable) as the benefit to avoid the user to
share it accidentally and would force him to explicitly express sharing (as
pointed before).
What I'm trying to say is that Posix implementation is based on a context,
the C language, different than ours, C++ language, where we can avoid
sharing data when it's dangerous.

I wasn't talking about boost::noncopyable.

Is there another reason for making it copyable, other than posix providing
an identifier value?

Also as pointed by others, it goes agains RAII based design to force the
user to explicitely release resources.

>  [...]By the way, in this example:
>>
>>
>> #if defined(BOOST_WINDOWS_API)
>>     typedef boost::asio::windows::stream_**handle pipe_end;#elif
>> defined(BOOST_POSIX_API)
>>     typedef boost::asio::posix::stream_**descriptor pipe_end;#endif
>>
>>     boost::asio::io_service io_service;
>>     pipe_end pend(io_service, p.source);
>>
>>
>> Can't there be a utility function that would provide the right type
>> depending on the target platform?
>>
>
> I wonder whether this should be done in Boost.Asio? But if I compare
> windows::stream_handle or posix::stream_descriptor there are some slight
> differences. Then we are at the core problem again we struggle with in
> Boost.Process for several years: What do we do with differences between
> platforms if we don't like #ifdefs? Either we support the minimum set of
> cross-platform features or implement no-ops on those platforms a feature is
> not supported on or invent a new high-level layer abstracting the
> differences away?
>

Looks like a not that simple problem.
My first reflex would be to ask why is it two totally different types?
Boost.Asio doesn't provide a type that would use the platform-specific type
in it's implementation?
I'm not sure to understand exactly why different types are needed here.
(not a boost asio specialist either...)

>
>  [...]If this library is proposed to the standard later, removing any
>> macro use
>>
>> for the user would be mandatory anyway.
>>
>
> Thanks for the encouragement! I'd already be happy if we can get something
> into Boost after six years. ;)

I agree ^^;

Maybe can you provide us a list of different cases where platform-specific
macros seems necessary? If the tutorial doesn't list them all already.
That way we could try to find a way to eliminate them. I'm sure most of
them can be encapsulated in utility functions or optional strategies
provided to child.
After all it seems that most cases you used macros in the tutorials are
custom behaviours that could be injected into child or something wrapping
it.

In the end the only two concerns I see in this discussions are
 1. Requiring user to use macros for general cases
 2. child isn't really idiomatic RAII

I'm sure those problems can be solved in no time and boost process can be
reviewed again. :)

Joel Lamotte