Open patryk4815 opened 2 weeks ago
The Linux kernel supports a range of 33 different real-time signals, numbered 32 to 64. However, the glibc POSIX threads implementation internally uses two (for NPTL) or three (for LinuxThreads) real-time signals (see pthreads(7)), and adjusts the value of SIGRTMIN suitably (to 34 or 35). Because the range of available real-time signals varies according to the glibc threading implementation (and this variation can occur at run time according to the available kernel and glibc), and indeed the range of real-time signals varies across UNIX systems, programs should never refer to real-time signals using hard-coded numbers, but instead should always refer to real-time signals using the notation SIGRTMIN+n, and include suitable (run-time) checks that SIGRTMIN+n does not exceed SIGRTMAX.
adjusts the value of SIGRTMIN suitably (to 34 or 35). Because the range of available real-time signals varies according to the glibc threading implementation
^ looks like when linking with libc 34+ or 35+ should be supported
To be clear then, the issue is just the lack of SIG.RTMIN
and SIG.RTMAX
fields in std.c
and std.os.linux
(and by extension std.posix
), yes?
@alexrp yes!
Zig Version
0.13.0
Steps to Reproduce and Observed Behavior
SIGRTMIN
Is needed for catching signal eg. fromtimer_create
Example C code using here: https://man7.org/linux/man-pages/man2/timer_create.2.html#EXAMPLESWithout LIBC:
With LIBC:
Expected Behavior
Crash on both. Or supported or both.