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

Subject: [boost] Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation
From: Renato Forti (re.tf_at_[hidden])
Date: 2013-10-07 14:00:41

Hi Vicente,

I liked a lot of your proposals! It puts the design of "app" in another new
direction, much more flexible.
I'll wait for other comments to see what other users think! If you have any
other idea comment, please share!

Thanks a lot
 --
 Renato Forti

-----Mensagem original-----
De: Boost [mailto:boost-bounces_at_[hidden]] Em nome de Vicente J. Botet
Escriba
Enviada em: segunda-feira, 7 de outubro de 2013 14:09
Para: boost_at_[hidden]
Assunto: Re: [boost] Boost.Application : Request for comments : Article /
Thread Pool / Other Features / Documentation

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-Threa
> d-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

_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost