Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
because settimeofday() may break the pthread_cond_timedwait().

Attached patch uses CLOCK_MONOTONIC and clock_gettime. But I don't know
how to write appropriate configure script.
"-lrt" is also needed to use clock_gettime() but I don't know how to add
it to LIBS.

See also #10278.

> Using CLOCK_MONOTONIC is better than CLOCK_REALTIME (default) for GIL
> because settimeofday() may break the pthread_cond_timedwait().

Indeed.
A couple remarks:
- regular locks and conditions variables exposed by the threading module suffer from the same problem
- POSIX semaphores are also affected, but you can't select an alternative clock source
- actually, CLOCK_MONOTONIC is affected by NTP adjustements: while it's guaranteed not to go backward, its rate can be affected

Did you really encounter this problem, or is this just a theoretical concern?

The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.

Antoine Pitrou wrote:
> 
> The patch is ok on the principle, but we do need a check that CLOCK_MONOTONIC is supported at build time.

I think we need both: a check at build time to avoid
compiler errors and a check at runtime whether the deployment
platform supports the clock, plus a fallback solution in case
it is not available.

> The patch is ok on the principle, but we do need a check
> that CLOCK_MONOTONIC is supported at build time.

timemodule.c is now using "#ifdef CLOCK_MONOTONIC".

Marc-Andre is right, a runtime check is probably also needed.
(for example with mismatching kernel/libc)

pthread_condattr_setclock() result should be checked.

"The pthread_condattr_setclock() function may fail if:

EINVAL The value specified by clock_id does not refer to a known clock, or is a CPU-time clock."

See also #14222. Python 3.3 has a new time.steady() function.