| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* add struct ul_timer as API abstraction to hide differences between
timer_create() and setitimer()
* add setitimer() detection to ./configure.ac
* add fallback code to use setitimer() if timer_create() not available
(for example on OSX)
Addresses: https://github.com/karelzak/util-linux/issues/584
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
| |
Signed-off-by: Karel Zak <kzak@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flock(1) uses the timer facility to interrupt a blocking flock(2)
call. However, in a pathological case (or with a sufficiently short
timeout), the timer may fire and the signal be delivered after the
timer is set up, but before we get around to doing the flock(2)
call. In that case, we'd block forever. Checking timeout_expired right
before calling flock(2) does not eliminate that race, so the only
option is to make the timer fire repeatedly. Having the timer fire
after we've returned from flock(2) is not a problem, since we only
check timeout_expired in case of EINTR (also, this firing after return
could also happen with the current code).
There is currently one other user of setup_timer (misc-utils/uuidd.c),
but in that case the signal handler simply exits. Future users of
setup_timer obviously need to ensure that they can tolerate multiple
signal deliveries.
Choosing 1% of the initial timeout as the repeating interval is
somewhat arbitrary. However, I put a lower bound of 0.01s, since
setting the interval much smaller than this may end up effectively
live-locking the process, handling a never-ending stream of signals.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
| |
|
|
|
|
|
|
|
| |
The only valid flag for timer_settime is TIMER_ABSTIME, which we
certainly don't want here. This seems to be harmless since
timer_settime doesn't validate the flags parameter, TIMER_ABSTIME is
universally 0x1, and no architecture has SA_SIGINFO == 1.
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
|
| |
|
|
|
|
|
|
|
|
| |
text-utils/tailf.c:69:21: warning: Using plain integer as NULL pointer
Since many 'struct option' has used zero as NULL make them more readable in
same go by reindenting, and using named argument requirements.
Reference: https://lwn.net/Articles/93577/
Signed-off-by: Sami Kerola <kerolasa@iki.fi>
|
| |
|
|
| |
Signed-off-by: Ruediger Meier <ruediger.meier@ga-group.nl>
|
|
|
It seems that static builds require -lpthread for timer_* functions.
It's better to keep it out of our libs (e.g. libmount) to avoid
unnecessary dependence.
Signed-off-by: Karel Zak <kzak@redhat.com>
|
