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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-09-10 07:26:06

Jeremy Maitin-Shepard wrote:
>
>    - 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 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 (designed so that exactly the same syntax
> could be used on both Windows and POSIX), and likewise a
> separate facility for providing an asio interface to a file
> descriptor/HANDLE (which also allows exactly the same syntax to
> be used on POSIX and Windows).

+1

That would be useful in many contexts.

> - As was observed in the discussion regarding setting up
>    stdin/stdout/stderr file descriptors on POSIX, it is
>    somewhat tricky to correctly set up child file descriptors.
>    As I believe it is fairly common on POSIX to want to set up
>    child file descriptors other than 0, 1, and 2, it would be
>    best for the library to provide explicit support for this,
>    rather than forcing the user to implement it manually in
>    context::setup.  A reasonable interface might be e.g.:
>    context::map_file_descriptor(int child_fileno, file_descriptor_t existing_descriptor);
>
> 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 on top of which other behaviors like
>    pipe, redirect, etc. could be implemented.

The problem with the suggested approach is that Windows winds up
with runtime errors if the child_fileno argument exceeds the
range.  It would be better to make that a compile time error.
The only way to do that is to use a template with the fileno
being a template argument.  Whether that takes the form of a
fileno class template or the fileno is a template argument for
map_file_descriptor (which must then be a member function
template), is another matter.

> - I think it would be cleaner for the POSIX and Windows
> extension interfaces to be in the form of a callback function
> (templated or boost::function), rather than a subclass of
> context that overrides the setup function.

Why do you make that assertion?  What becomes cleaner?

> - It seems that natively on Windows, unlike on POSIX, there is
> no notion of an array of command line arguments --- there is
> just a single string command line.  It seems it would be useful
> for Boost Process to allow a single string command line to be
> specified directly, in addition to the existing array
> (Container) interface which presumably does some sort of
> encoding into a single string on Windows.  Perhaps create_child
> can simply distinguish (at compile-time) between being passed a
> range of char and being passed a range of range of char.

A general facility for converting between the two representations
would be most helpful.  For example, one may wish to report the
command line, so accessing it as a single string is useful on
POSIX and Windows systems.  Likewise, one may wish to process the
arguments one at a time, as with argc/argv, even on Windows.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.