The structure passed to `sigaction()` left it's `sa_mask` member uninitialized.
Fixes: beb356b ("uloop: add support for user defined signal handlers")
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
Reuse and extend the existing signal waker pipe mechanism to add user
defined signal handling functionality to uloop.
This commit introduces two new api functions `uloop_signal_add()` and
`uloop_signal_remove()` along with a new structure type `uloop_signal`
to allow adding and removing arbitrary signal handlers.
Registered signal handlers are maintained in a linked list and matched
by their signo member value which allows registering multiple handlers
for the same signal numbers.
Upon registering a new signal handler, the existing handler is saved
in the `uloop_signal` structure. When removing the user defined signal
handler, the original behavior is restored.
The Lua binding has been updated as well to support the new signal
handler mechanism.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
So far, the only way to implement periodic interval timers was to use
one-shot uloop_timeout timers which are rearmed within their completion
callback immediately on expiration.
While simple, this approach is not very precise and interval lengths will
slowly drift over time, due to callback execution overhead, scheduling
granularity etc.
In order to make uloop provide stable and precise interval timer
capabilities, this commit introduces a new `uloop_interval` structure
along with the new related `uloop_interval_set()`, `uloop_interval_cancel()`
and `uloop_interval_remaining()` api functions.
Periodic timers are implemented using the timerfd facility an Linux and
kqueue EVFILT_TIMER events on macOS/BSD.
The Lua binding has been updated to include support for the new timer type
as well.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
- support reading the next timeout in order to determine the poll timeout
- add a callback for fd add/delete/update
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This uses the same return type as tv_diff so we don't need to check for
integer overflow.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: John Crispin <john@phrozen.org>
The uloop_timeout_remaining function is public and changing its return
type breaks ABI. Change the return type back to int, and return INT_MIN
or INT_MAX if the value returned by tv_diff would overflow integer.
Fixes: be3dc7223a ("uloop: avoid integer overflow in tv_diff")
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Jo-Philipp Wich <jo@mein.io>
Acked-by: John Crispin <john@phrozen.org>
The tv_diff function can potentially overflow as soon as t2->tv_sec is
larger than 2147483. This is very easily hit in ujail, after only
2147484 seconds of uptime, or 24.85 days.
Improve the behaviour by changing the return type to int64_t.
Fixes: FS#3943
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Some programs want to manage their own child life cycle without using
SIGCHLD signal handler. In these cases, uloop is reaping children for
them because they don't have SIGCHLD handler set. This patch makes it
possible to disable reaping children through 'uloop_handle_sigchld'
variable.
Signed-off-by: Petar Paradzik <petar.paradzik@sartura.hr>
When uloop_process_add() is called outside of uloop_run(), i.e. not
from a callback (which is the case of at least utrace and ujail),
child events can be missed. The reason is that when SIGCHILD handler
is installed in uloop_run(), after the uloop_process_add() is called,
then an initial signal could be missed.
Commit 4e3a47a ("uloop: use a waker for notifying sigchld and loop
cancel events", 2016-06-09) solved a similar problem and introduced
uloop_init() but forgot to move a call to uloop_setup_signals() there.
This is what this commit does.
Now, uloop_process_add() can be called any time after uloop_init()
without missing any event.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Yousong Zhou <yszhou4tech@gmail.com>
Variable confusion was breaking timers
Fixes: 368fd26458 ("uloop: allow specifying a timeout for uloop_run()")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
This can be useful for cleanup with pending timers, or for hooking into
existing code that does not use uloop
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Recent glibc warns if result of read() or write() is unused.
Added a retry in case of EINTR, all other faults are silently discarded.
Signed-off-by: Eyal Birger <eyal.birger@gmail.com>
-----
- I was not able to reproduce the EINTR case, but it seems to be the right
thing to do
- Retrying on EAGAIN in this case would be weird as there is no one to read
from the other end of the pipe. We could call waker_consume() directly but
since the size of the message is just one byte, I think this would be dead
code
When a process quits in response to a signal it handles, it should to so
be re-sending the signal to itself. This especially important for SIGINT,
as is explained in [1].
uloop currently hides the reason for quitting uloop_run(). Fix this by
returning the signal that caused the loop to quit (or 0 when uloop_end()
was used), so a program using loop an comply with [1].
[1] https://www.cons.org/cracauer/sigint.html
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Fix a race condition when do_sigchld, uloop_cancelled were set just
before epoll_wait(timeout=-1), resulting the loop stuck in the syscall
without noticing the events just happened
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Most app don't want to crash because of unhandled SIGPIPE. It could
happen is such trivial situations like writing to socket.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
In some conditions, an application is interested in errors happening
on a file descriptor and might be able to resolve the issue in the
callback function.
This patch adds a flag to notify the uloop framework that errors
should be passed to the callback function, instead of silently
removing the fd from the polling set.
Signed-off-by: Karl Vogel <karl.vogel@gmail.com>
uloop_run calls uloop_setup_signals() to set up signal handling before the while
loop, but does not remove the signal handling after the loop has ended. This can
cause problems for for example applications using the ubus file descriptor in
their own event loops, and perhaps with their own signal handling.
This patch stores the signal handle that was in place when the initial
uloop_run() call was made, and restores the handle when this call returns.
For recursive calls, the signal handler is not updated.
One use-case I experienced was an application that subscribed to several ubus
objects and used the ubus file descriptor in its own event loop. Even though
ubus_register_subscriber() (which calls uloop_run()) had returned, the signal
handler was not removed. This caused SIGINT not to be caught by the application.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
When a fd gets deleted internally due to errors, fd->registered gets set
to false before events are moved to the staging array.
This leads to pending events not getting cleared properly when the fd
user finally calls uloop_fd_del.
Fix this by moving the check down and always checking for pending
events.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
uloop timeouts are calculated based on a time value that was fetched
before any callbacks were executed. Hence, the next timeout is off by
the time the callback execution took which can lead to strange side
effects.
Fix this by calculating the next timeout based on a fresh time value.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
With multiple recursive calls to uloop_run, the callback for the same fd
can be run multiple times from different levels in the stack.
Prevent this by tracking the stack of uloop_fd callbacks and buffering new
incoming events for fds already on the stack.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Recursive calls to uloop_run() need to process already fetched events
first, before running kqueue/epoll to get more.
The state of cur_fd/cur_nfds and the event list needs to be maintained
properly to prevent accidental running of events pointing at deleted
uloop_fd structs.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Sometimes after re-arming a fd, an initial event for reads is not generated,
even though there is data pending. Work around this by making the trigger
level-triggered first, then switching to edge trigger after processing the first
event.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
