profiler: SystemTime::now() in signal handler has uncertain async-signal-safety on non-Linux platforms

[korniltsev-grafanista-yolo-vibecoder239]

⚠️ AI-generated issue — requires human investigation before acting on it.

Summary

perf_signal_handler in src/profiler.rs calls SystemTime::now() to record the sample timestamp. On Linux, this ultimately calls clock_gettime(CLOCK_REALTIME, ...) which is listed as async-signal-safe by POSIX. However, on other platforms (macOS, FreeBSD) and with some libc configurations, the implementation may use internal synchronisation primitives or VDSO calls that are not formally guaranteed to be async-signal-safe by Rust's spec.

Location

src/profiler.rs, line 386:

let sample_timestamp: SystemTime = SystemTime::now();

This is called inside perf_signal_handler, which is declared as async-signal-safe.

Impact

• On Linux with glibc/musl, clock_gettime via VDSO is safe in practice.
• On macOS, gettimeofday/clock_gettime implementations may acquire locks in certain edge cases (e.g. timezone changes, NTP updates).
• If SystemTime::now() is not async-signal-safe on a given platform, it could cause deadlocks or corrupted state when the signal interrupts a thread that holds an internal libc time lock.

Expected behaviour

Either:

1. Document the platforms where this is known-safe and add a CI note for others.
2. Replace with a direct libc::clock_gettime(libc::CLOCK_REALTIME, ...) call which is explicitly AS-safe per POSIX, avoiding Rust's std layer.
3. Use CLOCK_MONOTONIC instead of real time (also AS-safe, and avoids NTP jump edge cases).