Author jyasskin
Recipients gps, jyasskin, pitrou
Date 2009-11-17.17:54:23
SpamBayes Score 4.02444e-05
Marked as misclassified No
Message-id <5d44f72f0911170954l5c5ab6c0s4d9af5d4db4fd257@mail.gmail.com>
In-reply-to <1258475392.3472.24.camel@localhost>
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.

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.
History
Date User Action Args
2009-11-17 17:54:26jyasskinsetrecipients: + jyasskin, pitrou, gps
2009-11-17 17:54:23jyasskinlinkissue7316 messages
2009-11-17 17:54:23jyasskincreate