Boost logo

Boost :

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]

Boost list run by bdawes at, gregod at, cpdaniel at, john at