If signalfd(2) interface is available, prefer it over traditional signal
handlers. This is mostly intended to drop dedicated signal handling thread
and hook signal processing into libevent event loop in the most natural way.
Signed-off-by: Dmitry Antipov <dantipov@cloudlinux.com>
Signed-off-by: Dmitry Antipov <dantipov@cloudlinux.com>
This way all the qualifiers (`const`, `volatile`, `mutable`) are grouped
together, e.g. `T const* const x` vs. `const T* const x`. Also helps reading
types right-to-left, e.g. "constant pointer to constant T" vs. "constant
pointer to T which is constant".
There're places where manual intervention is still required as uncrustify
is not ideal (unfortunately), but at least one may rely on it to do the
right thing most of the time (e.g. when sending in a patch).
The style itself is quite different from what we had before but making it
uniform across all the codebase is the key. I also hope that it'll make the
code more readable (YMMV) and less sensitive to further changes.
Factor out demonization implementation to platform-specific files.
Implement daemonization on Windows using service API. Improve *NIX
implementation by handling signals asynchronously to prevent potential
issues of running complex code inside the handler.
Charles Kerr