On Mon, 29 Mar 2010 18:03:36 +0300, Dmitry Goncharov <dgoncharov@unison.com> wrote:
[...]Just wonder, Boris, what made you reimplement my original proposal?
As we probably should start a new thread to discuss the signal handler I try to keep my answer short. But the main reason why I reimplemented the signal handler was that a Boost.Asio extension should follow Boost.Asio patterns (assuming that the goal is to improve chances that Christopher ships a signal handler with Boost.Asio one day).
You new version is no longer uses a mutex inside a signal handler. It still improperly handles errno, doesn't care about blocking inside a signal handler, doesn't care about setting FD_CLOEXEC, doesn't pass siginfo to the user, doesn't let the user to associate a signal with a file descriptor. Besides, it uses a thread, a mutex, a condvar, a shared_ptr, a weak_ptr, a deque and a map. None of this is required.
I welcome test cases to improve the implementation (and of course patches). However your signal handler for example doesn't support a synchronous wait. As all other Boost.Asio I/O objects support both synchronous and asynchronous I/O there is something fundamental missing. While my signal handler's implementation can surely be improved your signal handler's interface doesn't even fulfill basic requirements of a Boost.Asio I/O object. Boris