On Wed, 28 Oct 2009 23:18:04 +0100, Rutger ter Borg 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 #include 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