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 gregory.p.smith, hobb0001, jyasskin, pitrou, rnk
Date 2010-07-12.16:08:42
SpamBayes Score 0.2490789
Marked as misclassified No
Message-id <1278950924.27.0.0231463989044.issue8844@psf.upfronthosting.co.za>
In-reply-to
Content
Actually, there is a problem in Lock.acquire and RLock.acquire. If a signal occurs and signal handling returns successfully, acquiring the lock will be retried without decrementing the timeout first. Therefore, we may end up waiting longer than the user wanted.

I'm not sure how to tackle that: either we accept that an incoming signal will make the wait longer, or we fix it by properly decrementing the timeout (which will complicate things a bit, especially for cross-platform time querying - but see issue9079 which might help us).
History
Date User Action Args
2010-07-12 16:08:44pitrousetrecipients: + pitrou, gregory.p.smith, jyasskin, rnk, hobb0001
2010-07-12 16:08:44pitrousetmessageid: <1278950924.27.0.0231463989044.issue8844@psf.upfronthosting.co.za>
2010-07-12 16:08:42pitroulinkissue8844 messages
2010-07-12 16:08:42pitroucreate