This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]