signalfd may behave differently to sigaction/signal, so to avoid
breaking libevent users (like [1], [2]) disable it by default.
[1]: https://github.com/tmux/tmux/pull/3621
[2]: https://github.com/tmux/tmux/pull/3626
Also signalfd is not that perfect:
- you need to SIG_BLOCK the signal before
- blocked signals are not reset on exec
- blocked signals are allowed to coalesce - so in case of multiple
signals sent you may get the signal only once (ok for most of the
signals, but may be a problem for SIGCHLD, though you may call
waitpid() in a loop or use pidfd)
- and also one implementation problem -
sigprocmask is unspecified in a multithreaded process
Refs:
- https://lwn.net/Articles/415684/
- https://ldpreload.com/blog/signalfd-is-useless
Refs: https://github.com/libevent/libevent/issues/1460
Refs: #1342 (cc @dmantipov)
Linux-specific signal handling backend based on signalfd(2)
system call, and public function event_base_get_signal_method()
to obtain an underlying kernel signal handling mechanism.
Signed-off-by: Dmitry Antipov <dantipov@cloudlinux.com>
By default we are using CLOCK_MONOTONIC_COARSE, but if
EVENT_BASE_FLAG_PRECISE_TIMER isset, then CLOCK_MONOTONIC will be used,
however this will also enable timerfd, while this is not always what
someone wants, hence add a flag to control this (by default the old
behavior is preserved, set new flag to change it).
- Documentation for `bufferevent_compat.h` and `rpc.h` is not generated
since the `@file` command is missing. It can be fixed by adding
`@file` in file comment block.
- The briefs of buffer.h,bufferevent.h and some other files are missing.
Adding `@brief` command can fix it.
- The parameters in the function declaration are different from the
parameters following the `@param` command.We should change them to the
same.
- Documentation of `watch.h` is not generated since `watch.h` has not
been added to the Doxyfile `INPUT` tag.
- Add link to the watch.h in event.h
Currently it's not clear as to whether "first make it non-pending and
non-active" sentence requires user to take some action (e.g. call event_del(),
which event_free() already does internally) or just describes what this
function does from the developer point of view.
This commit provides an interface for accessing and resetting the maximum
number of events in a given period. This information provides better insight
into event queue pressure.
There was actually a bug in the original version of this: it tried to
run the finalizers after (potentially) setting current_base to NULL;
but those finalizers could themselves (potentially) be invoking stuff
that needed to know about the current event_base. So the right time to
do it is _before_ clearing current_base.
