Message 110105 - Python tracker

➜

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.

In-reply-to
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>

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

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:44	pitrou	set	recipients: + pitrou, gregory.p.smith, jyasskin, rnk, hobb0001
2010年07月12日 16:08:44	pitrou	set	messageid: <1278950924.27.0.0231463989044.issue8844@psf.upfronthosting.co.za>
2010年07月12日 16:08:42	pitrou	link	issue8844 messages
2010年07月12日 16:08:42	pitrou	create

homepage