I agree, thanks for your comment. Thanks -- Renato Forti -----Mensagem original----- De: Boost [mailto:boost-bounces@lists.boost.org] Em nome de Juan Carlos Franzoy Enviada em: segunda-feira, 7 de outubro de 2013 14:07 Para: boost@lists.boost.org Assunto: Re: [boost] Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation 2013/10/7 Renato Forti :

Hi All, In this email I would like to discuss some areas of Boost.Application.

01) Thread Pool functionality

It seems that a lot of functionality could be proposed: snmp, configuration, log, clustering facilities (group protocols), threads, IPC, database connectors, etc. They will turn Boost.Appliction a framework more like a Java Application Container than a boost library. I humbly think that a general library ideally should have a single responsibility and be easily integrated with other libraries. In my work I mantain a library with the oposite aproach: a framework. It manages the startup, shutdown, pause and resume as a windows service, a unix daemon or a console program. It provides a configuration and a log api, and I am thinking about adding snmp support. But the context is completely different, in my company it is done to "force" that all aplication are written in a similar way. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

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

Hi Bjorn, Thank you for the warning and help, I will see "signs" in more detail, I think to use Asio to manipulate the signals to me. -----Mensagem original----- De: Boost [mailto:boost-bounces@lists.boost.org] Em nome de Bjorn Reese Enviada em: terça-feira, 8 de outubro de 2013 05:26 Para: boost@lists.boost.org Assunto: Re: [boost] Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation On 10/07/2013 05:43 PM, Renato Forti wrote:

05) Boost.Application Resources

[Other Boost.Application Resources]

* Download Last Version https://sourceforge.net/projects/boostapp/

Your POSIX signal handler (common_application_imp::sighandler) ends up calling a boost::function provided by the user. In other words, the user callback is executed from the signal handler. This is problematic because it is very limited what you are allowed to do in a signal handler, and your users should not be required to handle those restrictions. In fact, your examples violate those restrictions. Briefly put, you cannot use any function that may allocate memory, because most memory managers are not designed to be reentrant. POSIX lists exactly which system calls are allowed. Look for 'async-signal- safe' in: http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html A common workaround is to create a pipe (e.g. with the pipe(2) system call) and let the application and the signal handler interact via that pipe, because the write(2) system call is async-signal-safe (but note that fwrite, or any other buffered variant are not safe.) Usually, the signal handler will simply send a single byte per signal to the application. On another note, I suggest that you use sigaction() instead of signal() to install signal handlers. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost