All, I have tried get timer ID into handler, 'man signals' say me:
siginfo_t {
// ...
int si_overrun; /* Timer overrun count; */
int si_timerid; /* Timer ID; POSIX.1b timers */
// ....
}
Ok, but runtime I have si_timerid = 0 ! with successful run timer_create() function. Interesting... Next unroll - check definition this structure. 'signal.h' include 'siginfo.h' where exist definition and siginfo_t hasn't si_timerid, but have define
#define si_timerid _sifields._timer.si_tid
siginfo_t has union with few anonymous structures inlude '_timer' with tree fields, third also union. Will try to check its!
printf("$%08X ", s_info -> _sifields._timer.si_tid ); //
printf("=%08X ", s_info->si_timerid );
printf("$%08X ", s_info->_sifields._timer.si_sigval.sival_int ); // TIMER_ID !!!
// from 'siginfo.h': # define si_overrun _sifields._timer.si_overrun
printf("=%08X ", s_info->si_overrun ); // Not error.
// printf(" >$%08X ", s_info->_sifields._timer.si_overrun ); // Error!
// EXPANDS TO: printf(" >$%08X ", s_info->_sifields._timer._sifields._timer.si_overrun );
And when I try to use s_info->_sifields._timer.si_overrun
I have one more error: twice expand macro because defined part and expand part have the same symbols!
filed si_timerid
doesn't return timer ID.
Wrong headers or what?! Where and how to report it?
filed si_timerid doesn't return timer ID.
That's right, it doesn't.
Wrong headers or what?!
What.
That field is Linux specific. It is documented on the Linux sigaction(2) manual page, which says of it:
- Signals sent by POSIX.1b timers (since Linux 2.6) fill in
si_overrun
andsi_timerid
. Thesi_timerid
field is an internal ID used by the kernel to identify the timer; it is not the same as the timer ID returned bytimer_create
(2
). [...] These fields are nonstandard Linux extensions.
(emphasis added).
Where and how to report it?
There is nothing to report. It is normal that the value of the field you are looking at is not the same as the timer ID provided to you by timer_create()
. It probably is not useful to look at that field at all, and certainly not if your code is intended to be portable beyond Linux.
In the same vein, it is rarely useful to read system headers themselves. You should find pretty much everything you are meant to rely upon documented elsewhere, and that documentation is usually easier to digest anyway.