Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-10 19:59:06

On 09/10/2010 03:49 PM, Ilya Sokolov wrote:
> On Thu, 09 Sep 2010 20:02:54 -0700
> Jeremy Maitin-Shepard<jeremy_at_[hidden]>  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]