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 jyasskin
Recipients gps, jyasskin, pitrou
Date 2009-11-17.16:05:51
SpamBayes Score 2.1972268e-05
Marked as misclassified No
Message-id <1258473954.48.0.520173884773.issue7316@psf.upfronthosting.co.za>
In-reply-to
Content
I don't object strongly, but since locks are "supposed" to be held for 
short amounts of time, a timeout shouldn't be that useful, and when 
people really need it they can put it together with a condition 
variable. Timeouts also interact poorly with condition variables: you 
can time out the initial acquire, but if you wait on a condition there's 
no place to put the timeout on the reacquire.

Given that it's hard to pick a timeout in most cases anyway, I think 
it'd be a much bigger win to figure out thread interruption. (Yes, I 
know that's hard, and that I promised to do it a long while ago and 
never got around to it.)

That said, I have no objections at all to adding an internal timeout 
ability for use by Condition.wait, and if you're still enthusiastic 
about adding the timeout given the above argument, I won't block you.
History
Date User Action Args
2009-11-17 16:05:54jyasskinsetrecipients: + jyasskin, pitrou, gps
2009-11-17 16:05:54jyasskinsetmessageid: <1258473954.48.0.520173884773.issue7316@psf.upfronthosting.co.za>
2009-11-17 16:05:52jyasskinlinkissue7316 messages
2009-11-17 16:05:51jyasskincreate