CLOCK_* clockid_t value macros

CLOCK_* clockid_t value macros

[Roland McGrath]

Is there any problem with defining the CLOCK_PROCESS_CPUTIME_ID and
CLOCK_THREAD_CPUTIME_ID macros even on the systems that don't support them?
I would like to consolidate the bits/time.h files and this is the only
actual difference among any of the supported configurations.

It seems fine to me to define them.  They are not specified by POSIX.1-2001
(only CLOCK_REALTIME is), but permitted.  The spec just says that clock_*
will return EINVAL if given an invalid clockid_t, and so it will for
CLOCK_PROCESS_CPUTIME_ID or CLOCK_THREAD_CPUTIME_ID on systems with no
HP_TIMING support.

I think it's reasonable that programs should need to cope with EINVAL for
these when the macros are present even on machines that currently have
them.  One might very well have a libc where e.g. rdtsc has been disabled
for hardware that doesn't support it.

Does anyone see a problem with this?

Re: CLOCK_* clockid_t value macros

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland McGrath wrote:

> Is there any problem with defining the CLOCK_PROCESS_CPUTIME_ID and
> CLOCK_THREAD_CPUTIME_ID macros even on the systems that don't support
> them?
> I would like to consolidate the bits/time.h files and this is the only
> actual difference among any of the supported configurations.


In theory it shouldn't be a problem since users have to check
_POSIX_CPUTIME and _POSIX_THREAD_CPUTIME first.  But there is definitely
code out there which will break.  I don't have personally problems with
this.

- -- 
- --------------.                        ,-.            444 Castro Street
Ulrich Drepper \    ,-----------------'   \ Mountain View, CA 94041 USA
Red Hat         `--' drepper at redhat.com `---------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9sGlw2ijCOnn/RHQRAgk2AJ0V0+mzZx5GRgaOVhxA00amaR5uAgCfUz7t
miCO9JQ1hWNrOJuI5vOxEmw=
=pvYV
-----END PGP SIGNATURE-----