Hello! Thanks for the persisted notion to stop wheel-inventors :) As I understand, wait_termination_signal by design offers only synchronous interface. To do graceful signal handling one have to do blocking call to wait(). In some cases it implies extra work and disputable design. e.g. in application that does I/O (almost every server application does) one have to create thread for signal waiting and further sending terminate event to the main thread. This is what boost::application::signal_binder + boost::asio::signal_set have under the hood. Meanwhile, some I/O-providing libraries offer signal-safe interrupt methods, for instance libfcgi offers FCGX_ShutdownPending(). /* Afaik, fcgi application is in your todo list. */ In such cases signal handling can be done via sigaction(2) and no extra threads. I would like to have such an opportunity. Also it might be a better design to force a user to do a synchronous wait_for_termination() call in a separate manually created thread than implicitly create io_service's runner thread on startup. I think it worth noting in documentation that SIGUSR1 is reserved for internal purposes. What do you think about self pipe built-in functionality? It is a widely used trick. I think it can be implemented as an aspect in a quite straightforward way. I also noticed some typos/minor errors in documentation: http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica... - singliton, classe, sincronized http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_applica... - Boost.Thread - "in order to link programs that use Boost.Application:" may be replaced with "in order to compile programs that use Boost.Application:", because compilation will fail on header lookup stage if the system lacks required libraries - "Std TypeIndex" may be respelled like "std::type_index", imo the latter looks much prettier -- Regards, Stas.