Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-08-17 16:20:30
On Tue, 17 Aug 2010 19:59:43 +0200, Daniel Trebbien <dtrebbien_at_[hidden]>
> [...]Excellent! I was hoping that the basic functionality would be
> platform-independent. Now it is (mostly).
> Is there a way to further remove platform dependence in handling the
You mean the WIFEXITED et al macros? We had a status class in previous
Boost.Process versions which encapsulated the exit code. However the
design of the class was not really cross-platform as member functions like
exited() were clearly added for POSIX systems only and didn't make sense
on Windows (exited() for example always returned true). Thus the question
is what to make platform-independent if a concept doesn't exist on a
> [...]Interesting. Just out of curiosity, how did you implement
> asynchronous pipes
> on Windows? Reads and writes from/to anonymous pipes that are created
> CreatePipe are blocking.
Yes, exactly! That's why named pipes must be used on Windows for
asynchronous I/O (a behavior class called named_pipe is provided by the
> [...]Here are some of my wish list items:
> * Templating of the char type to support wchar_t. The "wchar_t version"
> would use the wide versions of Windows functions: CreateProcessW, etc.
The problem is then what to do on POSIX platforms (as there is no wide
version of execve() for example)?
> * The ability to allocate within another process' address space, as well
> read/write from/to another process' memory.
I think you are looking for Boost.Interprocess. :-)
> * Integration with Boost Filesystem
Where would you like to see support? Passing a path object to
create_child() for example?
> Also, two questions:
> * In the example that uses
> what happens if the child process exits before async_wait is called, and
> before the status object is created? Will the end_wait function still be
> * Do I need to call wait or async_wait to prevent the accumulation of
Thanks for your feedback,