Boost logo

Boost :

Subject: Re: [boost] Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-10-07 13:08:42

Le 07/10/13 17:43, Renato Forti a écrit :
> Hi All, In this email I would like to discuss some areas of
> Boost.Application.
> 01) Thread Pool functionality
> One of the most recurring requests is that Boost.Application should provide
> Thread Pool functionality.
> A flexible Thread Pool can be a complex thing, need provide schedule
> polices, grow/reduce polices, Shutdown policies, deadline s and many others,
> and then I think that this feature devotes your own Boost library.
> The Boost.Application can be integrated easily with one Thread Pool provided
> by third parties, or the user can make one "specific" (Not flexible/Complex)
> to your needs, e.g.: I make a simple work queue model using Boost.Asio and
> Boost.Thread that I plug on Boost.Application, see these tutorial:
> * Creating a Work Queue (Thread Pool) Application Using Boost.Asio,
> Boost.Thread and Boost.Application
> -Application-Usin
> My question is: The boost users think that Boost.Application must provide a
> complex Thread Pool to be accepted?

I don't think it is good to couple thread pools and your library.

IMO the library provides several features that IMHO are orthogonal:

* different application modes interactive, daemon, ...
* signal management
* command line arguments and environment variables
* elapsed time

I wonder if these features/aspects of an application couldn't be
provided in a more independent way.


* At the bottom line, provide a way to instantiate specific aspects of
the single applicationcontext

  void application_ctrl::add<T>();
  T& void application_ctrl::get<T>();

* provide a simple way to provide different application modes
interactive, daemon, ...

  int application::server(fct);
  int application::interactive(fct);

* Provide a way to know if the application has been stopped, suspended
or running. We could associate a signal aspect with the application.
This signal class would allow to get the status of each one of the
signals managed, wait for a given signal to be ready or call a given
function on signal reception. E.g.




* command line arguments and environment variables: the main
functionality is already provided by Boost.ProgramOptions, You could
always create a class that takes the command line arguments and add them
to the application control as an aspect

* elapsed time. The user could use a specific stopwatch class


An example of main could be

int main(int argc, char *argv[]) {
   application_ctrl ctrl;
my_po& po = ctrl.add<my_po>(argc, argv);
   return application::as_server(ctrl, my_main);

The user can also use why not the singularity library to create a global
instance that can be seen from any part of the application

singularity<application_ctrl> ctrl;

application_ctrl& this_application() {
   return ctrl.get_global();

int main(int argc, char *argv[]) {
my_po& po = this_application().add<my_po>(argc, argv);
   return application::as_server(ctrl, my_main);

The advantages of this approach are:
* It is open: the user can add as many aspects as it needs.
* When used with the singularity library, all the aspects are accessible
from all the parts of the application, no need to pass the application
control parameter through all the functions.
* Different parts of the application can attach a callback on any signal.


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