This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [RFC] Posix compliant behavior of CLOCK_PROCESS/THREAD_CPUTIME_ID
- From: Roland McGrath <roland at redhat dot com>
- To: Christoph Lameter <clameter at sgi dot com>
- Cc: Ulrich Drepper <drepper at redhat dot com>, johnstul at us dot ibm dot com,Ulrich dot Windl at rz dot uni-regensburg dot de, george at mvista dot com,linux-kernel at vger dot kernel dot org, libc-alpha at sources dot redhat dot com
- Date: Fri, 1 Oct 2004 14:57:47 -0700
- Subject: Re: [RFC] Posix compliant behavior of CLOCK_PROCESS/THREAD_CPUTIME_ID
Sorry I haven't replied sooner. I don't think the facility offered by your
patch is enough by itself to be worth doing. That information about a
process is already available to itself via getrusage/times, though those
don't offer a per-thread sample.
I have been working on an alternate patch that implements more complete CPU
clock functionality. This includes access to other threads' and process'
times, potentially finer-grained information (based on sched_clock), and
timers. I will post this code when it's ready, hopefully soon.
As to supporting clock_settime, I think that is just plain not desireable.
I am not aware of any actual demand for it, and POSIX certainly does not
require that it be permitted. It's certainly undesireable to let a process
reset its actual totals as reported by getrusage, process accounting, etc.;
I gather your later revisions have at least avoided that pitfall. But I
don't really see the utility in letting applications use clock_settime on
their CPU clocks either. They can just save the starting value at the time
they would use clock_settime to reset it to zero, and compute the delta later.
Thanks,
Roland