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 gps, jyasskin, pitrou
Date 2009-11-17.16:29:38
SpamBayes Score 2.8421616e-06
Marked as misclassified No
Message-id <1258475392.3472.24.camel@localhost>
In-reply-to <1258473954.48.0.520173884773.issue7316@psf.upfronthosting.co.za>
Content
> 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.

I don't see how it's an objection. If you have a condition variable you
just use the cv's timeout feature, don't you? I guess there are already
tons of combinations which don't make sense anyway.

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

What do you mean by thread interruption? Cancellation?

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

Well, it's pretty basic functionality provided by the underlying OS
APIs, which is why I think it would be good to expose it. I remember
being annoyed by its absence, but it was a long time ago and I don't
remember which problem I was trying to solve.

(and it's safer than thread cancellation ;-))
History
Date User Action Args
2009-11-17 16:29:40pitrousetrecipients: + pitrou, jyasskin, gps
2009-11-17 16:29:38pitroulinkissue7316 messages
2009-11-17 16:29:38pitroucreate