Subject: [boost] Boost.Application : Request for comments : Article / Thread Pool / Other Features / Documentation
From: Renato Forti (re.tf_at_[hidden])
Date: 2013-10-08 07:45:57
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.
De: Boost [mailto:boost-bounces_at_[hidden]] Em nome de Bjorn Reese
Enviada em: terça-feira, 8 de outubro de 2013 05:26
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
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:
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:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk