Jeffrey Yasskin <jyass...@gmail.com> added the comment: >> 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.
The cv's timeout stops waiting for the cv to be notified, but then it just calls acquire() with no timeout. >> 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? Yes, sorry, I was using the Java term, which isn't particularly accurate. >> 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. Fair enough. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7316> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com