ziglang / zig

General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software.
https://ziglang.org
MIT License
33.7k stars 2.47k forks source link

sigaction don't support SIGRTMIN only when linking with libc #21189

Open patryk4815 opened 2 weeks ago

patryk4815 commented 2 weeks ago

Zig Version

0.13.0

Steps to Reproduce and Observed Behavior

SIGRTMIN Is needed for catching signal eg. from timer_create Example C code using here: https://man7.org/linux/man-pages/man2/timer_create.2.html#EXAMPLES

const std = @import("std");
const posix = std.posix;
const testing = std.testing;

test "bug sigaction" {
  const sig = 32;  // SIGRTMIN eg. for timer_create / POSIX.1-2008
  try std.posix.sigaction(sig, null, null);
}

Without LIBC:

# zig test ./bugs/bugs.zig 
All 1 tests passed.

With LIBC:

# zig test -lc ./bugs/bugs.zig 
1/1 bugs.test.bug sigaction...FAIL (OperationNotSupported)
/nix/store/ni7kxhi72zipa3m071rpgqbqjw9capdm-zig-0.13.0/lib/zig/std/posix.zig:5641:27: 0x1039855 in sigaction (test)
        .INVAL, .NOSYS => return error.OperationNotSupported,
                          ^
/work/bugs/bugs.zig:7:3: 0x103979f in test.bug sigaction (test)
  try std.posix.sigaction(sigBigerThen31, null, null);
  ^
0 passed; 0 skipped; 1 failed.

Expected Behavior

Crash on both. Or supported or both.

SIGRTMIN = 34/35 with libc SIGRTMIN = 32 without libc

patryk4815 commented 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

alexrp commented 1 week ago

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?

patryk4815 commented 1 week ago

@alexrp yes!