On 09/10/2010 03:49 PM, Ilya Sokolov wrote:
On Thu, 09 Sep 2010 20:02:54 -0700 Jeremy Maitin-Shepard<jeremy@jeremyms.com> wrote: [snip]
- The std::istream/std::ostream interface should be decoupled from the facility for retrieving the file descriptor (int) or Windows HANDLE, to avoid the overhead of allocating a streambuf
Could be solved using some form of lazy initialization
I suppose, but then you are still unnecessarily coupling a particular buffering and formatting/parsing facility with the management of subprocesses. With lazy initialization, even if you don't use any of the istream/ostream stuff, it still appears to "be there."
for those users that wish to access the file descriptor/HANDLE directly or use it with asio. Instead, the std::istream/std::ostream interface to a file descriptor/HANDLE could be provided as a separate, completely independent facility
Boost.IOStream?
Indeed, so Boost.Process can merely suggest using file_descriptor_source/sink from Boost.IOStream.
[snip]
Not sure what it means (. The most obvious extension to the current interface is:
context::set_behavior(fileno fn, function<...> b);
Yeah, sure. The redirection through a callback function seems unnecessary, though. See my reply to Boris Schaeling.
Potentially this same interface could be used on Windows, with child_fileno only valid in the range 0 to 2 (and with appropriate constants defined), and could thus serve as the lowest level interface
Why is it needed?
The enum approach you described would be better, I think.
[snip]
- One potential issue is that the Windows extension interface only exposes a (relatively) small subset of the functionality that can be configured on Windows. There seem to be numerous flags to CreateProcess that are not exposed by Boost.Process, and there are also two other functions, CreateProcessAsUser and CreateProcessWithLoginW, which allow specifying some additional options.
The interface could be made so complex that winapi would become easier.
I agree that is a concern, but you have to admit, the POSIX extension interface is quite powerful, to the point that there should be little need to bypass boost.process, while the Windows extension interface is not very powerful at all, only providing access to a small subset of the many options available. It is also the case, though, that in many ways process creation through the Windows API is much more straightforward than process creation through the POSIX API, and therefore the abstraction provided by a library like Boost Process is less critical on Windows, particularly for advanced uses. Potentially there could be two different extension interfaces on Windows, with the basic one similar to the existing one except for maybe allowing a few additional flags to be specified, and the advanced one could be fully general by allowing the user to call an alternate API function like CreateProcessWithLoginW, and users that don't need this level of control could simply ignore it.
[snip]