On Sun, Aug 19, 2012 at 12:12 PM, Boris Schaeling <boris@highscore.de>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