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