This is the mail archive of the
mailing list for the glibc project.
- From: Roland McGrath <roland at frob dot com>
- To: George Anzinger <george at mvista dot com>
- Cc: Richard Henderson <rth at twiddle dot net>, libc-alpha at gcc dot gnu dot org
- Date: Mon, 23 Feb 2004 13:38:06 -0800
- Subject: Re: __profile_frequency
> Richard Henderson wrote:
> > Um, so how's
> > 45 tim.it_interval.tv_sec = 0;
> > 46 tim.it_interval.tv_usec = 1;
> > 47 tim.it_value.tv_sec = 0;
> > 48 tim.it_value.tv_usec = 0;
> > 49 __setitimer(ITIMER_REAL, &tim, 0);
> > 50 __setitimer(ITIMER_REAL, 0, &tim);
> > 51 if (tim.it_interval.tv_usec < 2)
> > 52 return 0;
> > 53 return (1000000 / tim.it_interval.tv_usec);
> > supposed to work? AFAICS there's no reason for the kernel
> > (1) not to round down instead of up and (2) not do something
> > else legal like schedule in between the two __setitimer calls.
> Time is ALWAYS rounded UP as required by the standard. 2 is legal, however.
(2) is a red herring. it_value is zero, meaning the timer is off.
it_interval is what's being examined; scheduling events have no bearing on
it. It doesn't matter what happens in between, unless it's a signal
handler that calls setitimer to change the it_interval setting. The kernel
interface being exploited here is that it_interval is normalized to clock
granularity, so reading it back (which could be getitimer, btw, I dunno why
it calls setitimer the second time, but it's the same) gives you the
rounded value you need.