Message95388
> 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 ;-)) |
|
Date |
User |
Action |
Args |
2009-11-17 16:29:40 | pitrou | set | recipients:
+ pitrou, jyasskin, gps |
2009-11-17 16:29:38 | pitrou | link | issue7316 messages |
2009-11-17 16:29:38 | pitrou | create | |
|