Re: [Boost-users] Signal handler for Unix platforms

Subject: Re: [Boost-users] Signal handler for Unix platforms
From: Boris Schaeling (boris_at_[hidden])
Date: 2009-10-29 06:53:18

On Wed, 28 Oct 2009 23:18:04 +0100, Rutger ter Borg  
<rutger_at_[hidden]> wrote:

Hi Rutger,

> [...]have a couple of questions. Currently a part of the semantics is
>
> sh.add_signal( SIGUSR1 );
> sh.async_wait( handler );
>
> Wouldn't it be easier to be able to write
>
> sh.async_wait( SIGUSR1, handler );

this would work if you wait for only one signal unless ...

> Alternatively, if catching multiple signals by one handler is required,  
> one
> could think of something like
>
> sh.async_wait( sigusr1 | sigterm | sigabrt, handler );

... this notion is supported. But this would require to redefine every  
signal (like sigusr1 for SIGUSR1)? Is this practically possible? I wonder  
how many differences there are between platforms and if this causes more  
maintenance effort?

I also wonder what is more asio-like. If I look at the I/O objects of  
Boost.Asio it seems like they are always configured before an asynchronous  
operation is called. For example when using the deadline_timer  
expires_at() or expires_from_now() must be called before async_wait() is  
called.

> sh.async_wait( boost::asio::posix::any_signal, handler );

Same answer as above. :) Apart from that I wonder how many developers  
would benefit from boost::asio::posix::any_signal. Are there so many  
applications which need to wait for all signals?

> Does the signal ID belong in the signature of the handler function? Am I

Yes, please see the test cases test/sync.cpp and test/async.cpp. Here's a  
simple example:

----------
#include "signal_handler.hpp"
#include <boost/asio.hpp>
#include <signal.h>

void signal_handler(const boost::system::error_code &ec, int signal)
{
}

int main()
{
   boost::asio::io_service io_service;
   boost::asio::posix::signal_handler sh(io_service);
   sh.add_signal(SIGUSR1);
   sh.async_wait(signal_handler);
   io_service.run();
}
----------

> correct that support for real-time signals is missing at the moment?

Not sure as I never used real-time signals. :) Looking up real-time  
signals the difference is merely prioritized delivery times and signal  
queues? If that's all real-time signals should be supported. The signal  
handler puts signals into a std::deque<int> object and doesn't merge  
signals either (when you call wait() or async_wait() the next signal is  
fetched from the queue).

Boris