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

7 Oct 2013

      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@lists.boost.org] Em nome de Vicente J. Botet
Escriba
Enviada em: segunda-feira, 7 de outubro de 2013 14:09
Para: boost@lists.boost.org
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(argc, argv);
   ctrl.add();
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 ctrl;

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

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