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-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(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