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

The standard requires time to be rounded UP to the next resolution value. (2) not do something
else legal like schedule in between the two __setitimer calls.

Well, the above looks at interval, not the value, so a delay will not make a difference. All you should see is the rounded interval.


I don't know about the setitimer, but the posix set_timer call with a zero value part, by the standard, resets the timer and would not pass the above test.

Time to check the standard...

On alpha-linux 2.5.73, tim is always zero after the second call, which results in divide-by-zero FPE in __sprofil.

Why wouldn't this be the same as __getclktck?


r~




-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml


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