Re: [boost] Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation

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
>   
> http://www.codeproject.com/Articles/664709/Creating-a-Work-Queue-Thread-Pool
> -Application-Usin
>
> My question is: The boost users think that Boost.Application must provide a
> complex Thread Pool to be accepted?
Hi,

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.

E.g.

* 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.

stop_signal::is_ready();

stop_signal::wait();

stop_signal::on_signal(F);

* 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

  application_ctrl::get<stopwatch>().elapsed_time();

An example of main could be

int main(int argc, char *argv[]) {
   application_ctrl ctrl;
my_po& po = ctrl.add<my_po>(argc, argv);
   ctrl.add<stop_signal>();
ctrl.add<stopwatch>();
   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[]) {
   ctrl.create_global();
my_po& po = this_application().add<my_po>(argc, argv);
this_application().add<stop_signal>();
this_application().add<stopwatch>();
   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.

Best,
Vicente