mirror of
git://sourceware.org/git/glibc.git
synced 2026-09-08 23:58:31 +08:00
Adhemerval Zanella
9d528833ac
The current timer_create SIGEV_THREAD implementation has some
downsides:
1. There is no way to report failure at thread creation when a
timer triggers. It means that it might occur unreported and with
missed events depending of the system load.
2. The background thread is also kept in the background even when there
are no more timers, consuming resources and also misleading memory
profile tools (BZ 29705).
3. There is a lot of metadata that needs to be kept: a control
variable for helper thread creation, a list of active SIGEV_THREAD
timers, atfork handlers to cleanup the list.
4. timer_create does not propagate all thread attributes to the new
thread (BZ 27895).
5. Kernel might deliver in-flight events for a timer after it was
destroyed by timer_delete. The timer_helper_thread mechanism to
handle it does not cover all possible issue, which leads to
callbacks being wrongly triggered (BZ 32833).
This new implementation moves the thread creation to timer_create, so
any failure is reported to the caller. Also, the same thread will
serve multiple timers, thus there are no unreported missed events.
Avoiding parallel timer activation also avoids possible parallel
timer invocations seeing the same overrun value.
SIGTIMER is used internally and aliases SIGCANCEL (__SIGRTMIN). The
helper thread keeps it blocked while waiting for expirations with
sigwaitinfo, and unblocks it only around the notification function so
that an asynchronous pthread_cancel targeting the pthread_t obtained
from pthread_self within the notification is delivered and acted upon
(POSIX requires SIGEV_THREAD to behave as if a fresh thread serviced
each notification). Because the same signal number is unblocked
there, the SIGCANCEL handler is installed eagerly from timer_create:
otherwise a timer re-fire or a timer_delete wake reaching the
notification thread would hit the default disposition of __SIGRTMIN
and terminate the process. For the same reason timer_delete wakes the
helper with SIGTIMER queued with SI_QUEUE instead of tgkill, so the
wake is not mistaken for a cancellation by the handler.
Unblocking SIGTIMER during the notification forces overrun accounting
into userspace. The kernel only counts an expiration as an overrun
while a signal for the timer is still pending; but with the signal
unblocked every expiration that arrives during the notification is
delivered promptly to the handler and ignored, so the kernel never
leaves one pending and never counts it (timer_getoverrun would thus
always report zero). The handler instead counts these ignored
expirations, and timer_create adds the ones the kernel folded in while
the helper was blocked between firings, into a per-timer cumulative
counter returned by timer_getoverrun. The counter is never reset
across notifications (otherwise the overruns of a slow notification
would be lost when the next one starts) and saturates at
DELAYTIMER_MAX, matching the kernel. This lets an application detect a
notification function too slow for the interval and take corrective
action, such as re-arming the timer with timer_settime.
The notification runs under a cancellation landing pad rooted at the
wait loop: a pthread_cancel or a pthread_exit from the notification
function unwinds back into the loop, a cleanup handler resets all
internal thread state, and the helper serves the next firing instead
of terminating. This also avoids the need to recreate the thread for
a pthread_exit call (and the possible unreported missed events from a
failed thread creation).
It also prevents the re-use issue when a newly-allocated timer has
in-flight events being delivered by the kernel (BZ 32833).
Performance-wise it uses less CPU time for multiple thread activations,
although each thread now requires a sigwaitinfo which generates more
context-switches/page-faults (check comment 7 from BZ 30558). I would
expect that latency should improve, since it avoids a thread creation
for each timer expiration.
Checked on aarch64-linux-gnu, x86_64-linux-gnu and i686-linux-gnu.
This directory contains the sources of the GNU C Library. See the file "version.h" for what release version you have. The GNU C Library is the standard system C library for all GNU systems, and is an important part of what makes up a GNU system. It provides the system API for all programs written in C and C-compatible languages such as C++ and Objective C; the runtime facilities of other programming languages use the C library to access the underlying operating system. In GNU/Linux systems, the C library works with the Linux kernel to implement the operating system behavior seen by user applications. In GNU/Hurd systems, it works with a microkernel and Hurd servers. The GNU C Library implements much of the POSIX.1 functionality in the GNU/Hurd system, using configurations i[4567]86-*-gnu and x86_64-gnu. When working with Linux kernels, this version of the GNU C Library requires Linux kernel version 3.2 or later. Also note that the shared version of the libgcc_s library must be installed for the pthread library to work correctly. The GNU C Library supports these configurations for using Linux kernels: aarch64*-*-linux-gnu alpha*-*-linux-gnu arc*-*-linux-gnu arm-*-linux-gnueabi csky-*-linux-gnuabiv2 hppa-*-linux-gnu i[4567]86-*-linux-gnu x86_64-*-linux-gnu Can build either x86_64 or x32 loongarch64-*-linux-gnu Hardware floating point, LE only. m68k-*-linux-gnu microblaze*-*-linux-gnu mips-*-linux-gnu mips64-*-linux-gnu or1k-*-linux-gnu powerpc-*-linux-gnu Hardware or software floating point, BE only. powerpc64*-*-linux-gnu Big-endian and little-endian. s390x-*-linux-gnu riscv32-*-linux-gnu riscv64-*-linux-gnu sh[34]-*-linux-gnu sparc*-*-linux-gnu sparc64*-*-linux-gnu If you are interested in doing a port, please contact the glibc maintainers; see https://www.gnu.org/software/libc/ for more information. See the file INSTALL to find out how to configure, build, and install the GNU C Library. You might also consider reading the WWW pages for the C library at https://www.gnu.org/software/libc/. The GNU C Library is (almost) completely documented by the Texinfo manual found in the `manual/' subdirectory. The manual is still being updated and contains some known errors and omissions; we regret that we do not have the resources to work on the manual as much as we would like. For corrections to the manual, please file a bug in the `manual' component, following the bug-reporting instructions below. Please be sure to check the manual in the current development sources to see if your problem has already been corrected. Please see https://sourceware.org/glibc/wiki/Bugzilla%20Procedures for bug reporting information. We are now using the Bugzilla system to track all bug reports. This web page gives detailed information on how to report bugs properly. The GNU C Library is free software. See the file COPYING.LIB for copying conditions, and LICENSES for notices about a few contributions that require these additional notices to be distributed. License copyright years may be listed using range notation, e.g., 1996-2015, indicating that every year in the range, inclusive, is a copyrightable year that would otherwise be listed individually.