This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients brian.curtin, jnoller, kevinwatters, lemburg, nascheme, pitrou, rcohen, schmir
Date 2010-01-28.18:07:04
SpamBayes Score 3.474188e-05
Marked as misclassified No
Message-id <1264702100.3358.16.camel@localhost>
In-reply-to <1264596474.3631.13.camel@localhost>
Content
> It appears to be better to use clock_gettime(CLOCK_MONOTONIC) > where available and only use gettimeofday() as fallback solution > together with times(), ftime() and time(). Ok, I've tried and it's less good than expected. Using CLOCK_MONOTONIC absolutely kills efficiency. CLOCK_REALTIME is ok but it has no obvious benefits (microsecond resolution as given by gettimeofday() is probably sufficient). The explanation AFAICT is that pthread_cond_timedwait() waits for absolute clock values as given by CLOCK_REALTIME. CLOCK_MONOTONIC gives other values (the man page says: "represents monotonic time since some unspecified starting point"). These values are probably "in the past" as seen from pthread_cond_timedwait(), which implies a busy loop of waiting for the GIL to be released, inside of being suspended gracefully until the timeout. I can still produce a patch with only CLOCK_REALTIME but I'm not sure it's worth the code complication.
History
Date User Action Args
2010-01-28 18:07:06pitrousetrecipients: + pitrou, lemburg, nascheme, schmir, kevinwatters, jnoller, brian.curtin, rcohen
2010-01-28 18:07:05pitroulinkissue7753 messages
2010-01-28 18:07:04pitroucreate