Re: [boost] New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).

Subject: Re: [boost] New Version (0.4) of Boost.Application (Aspect Based) available to comments (RFC).
From: Stanislav Ivochkin (isn_at_[hidden])
Date: 2013-11-07 05:52:31

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_application/f_a_q_.html#boost_application.f_a_q_.is_boost_application_thread_safe_
- singliton, classe, sincronized

http://www.dokfile.com/appbeta4/docs/libs/application/doc/html/boost_application/dependencies.html
- 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.