Boost C++ Libraries

PrevUpHomeNext

8. Project position

8.1. History of changes
8.2. Pending work
  • Relicensed the code under the Boost Software License 1.0 only. The first version was available under both this license and the MIT one only to comply with Summer of Code guidelines.
  • The POSIX-specific bits of a child's exit status were split from the status class into a new posix_status class.
  • The status constructor was made private to prevent accidental construction by the user and the create_status function was added to aid in the creation of such objects from custom Child implementations.
  • Initial public release. This is what was presented at the end of the program under which Boost.Process was developed: Google's Summer of Code 2006.

This section contains a list of pending items in the library that should be addressed before it can be sent for a serious/formal review. Some of these are a simple matter of programming but others will require more consideration to decide the best way to solve them.

8.2.1. Code

  • Integrate with Boost.Asio to permit asynchronous notification of child process termination and availability of new data in output streams.
  • Add the ability to force/request the termination of a child process.
  • Make it possible to specify a timeout when waiting for child processes to terminate.
  • Parametrize classes that use strings to support wide characters.
  • Make the detail::launcher_base a public class? It can be useful to end users if they decide to implement a custom launcher.
  • Replace custom system_error with Boost.System's homologous when it is available.
  • Abstract cstdlib's EXIT_SUCCESS and EXIT_FAILURE.
  • Rename command_line::argument method; and add operator<<?
  • Make launcher::start a free function. Need to rename launcher to context.
  • Make child::wait return a constant object.
  • Make status' constructor private.
  • Remove command_line::get_arguments.
  • Separate the executable from the command_line class into its own object.
  • Allow to retrieve a handle for the current process. Need to reintroduce the process class being a parent of child and correct the use of Win32 HANDLEs in the former: they really should be identifiers.

8.2.2. Documentation

  • Add a Design decisions chapter.
  • Fix links to inherited methods. Don't know which is the best approach to address this.
  • Add some diagrams to illustrate interprocess communication.
  • Shorten "Motivation" section?
  • command_line's constructor: rename firstarg parameter to avoid confusion with subsequent parameters.
  • When process identifiers are fixed under Win32, document that process identifiers are integral types.
Copyright © 2006 Julio M. Merino Vidal

PrevUpHomeNext