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

Jilles Tjoelker jilles at stack.nl
Fri Jul 13 21:05:49 UTC 2012


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?

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

* 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.

* 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.

-- 
Jilles Tjoelker


More information about the freebsd-threads mailing list