Message95387
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. |
|
Date |
User |
Action |
Args |
2009-11-17 16:05:54 | jyasskin | set | recipients:
+ jyasskin, pitrou, gps |
2009-11-17 16:05:54 | jyasskin | set | messageid: <1258473954.48.0.520173884773.issue7316@psf.upfronthosting.co.za> |
2009-11-17 16:05:52 | jyasskin | link | issue7316 messages |
2009-11-17 16:05:51 | jyasskin | create | |
|