|
Home > Archive > Unix Programming > October 2006 > POSIX Timers and time of signal delivery
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
POSIX Timers and time of signal delivery
|
|
|
| Hello,
I'm playing around with the POSIX Timers API
cf. http://www.jaluna.com/doc/c5/html/Overview/x5408.html
It is possible to have the kernel deliver a given signal upon
timer expiration:
int timer_create(clockid_t clockid,
struct sigevent *evp, timer_t *timerid);
struct sigevent event;
memset(&event, 0, sizeof event);
event.sigev_notify = SIGEV_SIGNAL;
event.sigev_signo = SIGRTMIN;
I arm a periodic timer, then wait for the signal in sigwaitinfo()
When a signal is delivered, I need to know by how much I overslept.
I call clock_gettime() i.e. another system call. It seems somewhat
wasteful to take a trip back into kernel land to get some information
that could have been provided the first time.
Is it possible to have the kernel return a struct timespec giving the
time of the signal delivery, avoiding an extra system call?
If not POSIX, is there perhaps a Linux-specific solution?
Regards.
| |
| Chris Friesen 2006-10-25, 1:27 pm |
| Spoon wrote:
> When a signal is delivered, I need to know by how much I overslept.
> I call clock_gettime() i.e. another system call. It seems somewhat
> wasteful to take a trip back into kernel land to get some information
> that could have been provided the first time.
>
> Is it possible to have the kernel return a struct timespec giving the
> time of the signal delivery, avoiding an extra system call?
No particular answer to your question, but I thought I'd point out that
there is no particular reason why clock_gettime() needs to actually
incur the overhead of a syscall. Some architectures on some kernel
versions can do gettimeofday() without actually doing a syscall.
Alternately, if you're only trying to run on a particular type of
hardware there are usually architecture-specific ways of getting a
high-res timestamp. "rdtscll" on x86, "mftb/mftbu" on ppc, etc.
Chris
| |
| Maxim Yegorushkin 2006-10-25, 7:15 pm |
|
Spoon wrote:
> I'm playing around with the POSIX Timers API
> cf. http://www.jaluna.com/doc/c5/html/Overview/x5408.html
>
> It is possible to have the kernel deliver a given signal upon
> timer expiration:
>
> int timer_create(clockid_t clockid,
> struct sigevent *evp, timer_t *timerid);
>
> struct sigevent event;
> memset(&event, 0, sizeof event);
> event.sigev_notify = SIGEV_SIGNAL;
> event.sigev_signo = SIGRTMIN;
>
> I arm a periodic timer, then wait for the signal in sigwaitinfo()
You may well know it already, just in case, you can also get your
callback called by a system-created thread specifiying SIGEV_THREAD in
sigevent.
http://www.opengroup.org/onlinepubs...mer_create.html
http://www.opengroup.org/onlinepubs...ml#tag_02_04_01
> When a signal is delivered, I need to know by how much I overslept.
> I call clock_gettime() i.e. another system call. It seems somewhat
> wasteful to take a trip back into kernel land to get some information
> that could have been provided the first time.
>
> Is it possible to have the kernel return a struct timespec giving the
> time of the signal delivery, avoiding an extra system call?
May be this?
http://www.opengroup.org/onlinepubs...getoverrun.html
| |
| Chris Friesen 2006-10-25, 7:15 pm |
| Maxim Yegorushkin wrote:
>
>
> May be this?
> http://www.opengroup.org/onlinepubs...getoverrun.html
On linux at least, that incurs a system call. It also doesn't appear to
include the time spent by the process waiting to be run after the signal
was delivered.
Chris
|
|
|
|
|