threads/168417: pthread_getcpuclockid() does not work to specification

David Xu listlog2011 at gmail.com
Fri Jul 13 23:43:08 UTC 2012


On 2012/07/14 05:05, Jilles Tjoelker wrote:
> On Thu, Jul 12, 2012 at 08:00:18AM +0000, David Xu wrote:
>> The following reply was made to PR threads/168417; it has been noted
>> by GNATS.
>> From: David Xu <davidxu at freebsd.org>
>> To: bug-followup at freebsd.org, chris.hall at highwayman.com
>> Cc:
>> Subject: Re: threads/168417: pthread_getcpuclockid() does not work to specification
>> Date: Thu, 12 Jul 2012 15:51:02 +0800
>>   I have worked out a patch trying to fix the problem:
>>   http://people.freebsd.org/~davidxu/patch/cputime_clockid.diff
> Some comments:
>
> * Should clock_getcpuclockid() and clock_getthreadcpuclockid() be
>    syscalls or can the 2**31 reserved clock ids be hard-coded into libc
>    just like the other clock ids are?
why should I hard-code it ? is syscall so horrible ? why can't you
cache the thread's clock id if you want to frequently access it?
it is not gettimeofday which returns different value each time.
If it is hard-coded, how do I check if the pid is valid or I have permission
to get its CPU time? should clock_getcpuclockid always return successfully ?

> * Perhaps clock_getcpuclockid() should check if the pid is valid.
Yes

> * I think p_canwait() is not the right permission check. The p_canwait()
>    check is for wait4() and takes into account that denying at that point
>    completely breaks the process's tracking of its child processes. The
>    right permission check is probably p_cansee() because that's what the
>    kern.proc.* sysctls that return CPU time also check. The recently
>    added pget() function can perform pfind() and p_cansee() in one call.

Yes, p_cansee seems to be more wide, while p_canwait has better
granularity, it does seem not very right.

> * Why can a thread's CPU clock only be read from the same process? The
>    kern.proc.* sysctls allow querying any thread whose process you
>    p_cansee. However, the POSIX APIs only allow accessing threads within
>    the process because there is no pthread_t for other threads.
At the time, I am only programming for POSIX, and thread can not
be seen by other processes.



More information about the freebsd-threads mailing list