[SOLVED] Is sysinfo() async. signal safe?

Is sysinfo() async. signal safe?

This may be a silly question, but in Linux (RHEL 7/8) is sysinfo() (called from gcc 'C') async. signal safe?

That is, can it be safely called called from a 'C' signal handler?

Running 'man sysinfo' or 'info sysinfo' from a command line doesn't seem to mention one way or the other.

I was looking for a 'fast' way to get elapsed time (from a signal handler or 'normal' context).

Posix ('man signal-safety') seems to say that clock_gettime() is signal safe, although I've seen that glibc and Posix documentation don't always seem to agree on what is signal safe and what is not. At least for where I was looking.

For example at https://pubs.opengroup.org/onlinepubs/9699919799/ 'sleep()' is listed as signal safe under 'Signal concepts' where a list of POSIX signal safe functions is shown. (And also under 'man signal-safety' run from RHEL 8.5).

But 'info sleep' (from RHEL 8.5) shows sleep() as 'AS-Unsafe'. (As well in the document 'The GNU C Library Reference Manual 2.28' which I think matches the installed level of glibc).

I guess I'm also not even sure where the definitive documentation is supposed to be found (for this environment).

Solution

sysinfo is just thin system call wrapper and async-signal-safe:

00000000000feb00 <sysinfo@@GLIBC_2.2.5>:
   feb00:       mov    $0x63,%eax
   feb05:       syscall 
   feb07:       cmp    $0xfffffffffffff001,%rax
   feb0d:       jae    feb10 <sysinfo@@GLIBC_2.2.5+0x10>
   feb0f:       retq   
   feb10:       mov    0xbf359(%rip),%rcx
   feb17:       neg    %eax
   feb19:       mov    %eax,%fs:(%rcx)
   feb1c:       or     $0xffffffffffffffff,%rax
   feb20:       retq

But there is no vDSO acceleration for it, so it is going to be much slower than clock_gettime with either CLOCK_REALTIME or CLOCK_MONOTONIC on current systems.