From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2006-10-08 11:19:35
Peter Dimov wrote:
> It does what the specification says it does, so it is not "wrong" in this
> sense. I'm arguing that the specification needs to be changed.
... <snipped> ...
> The idea of supplying a predicate version is to guard against common user
> mistakes. For the ordinary wait, the predicate version ignores spurious
> wakeups. It is very easy to assume that spurious wakeups don't occur and
> write incorrect code based on this assumption. So we supply a version where
> they don't.
>
> For timed_wait, there is an additional source of subtle bugs, the fact that
> a timeout and a signal can both occur and be "delivered" to the same waiting
> thread. You can't express this in a simple true/false return value, so you
> have to map the three possible outcomes into two (the fourth outcome is a
> spurious wakeup and is never returned). I argue that the predicate version
> should attempt to guard against this additional incorrect user assumption
> (that only one of a signal occuring or a timeout elapsing happens and not
> both), too.
>
> To get back to you example,
>
> if (!timed_wait(lk, xt, pred) && !pred()) {
> // handle timeout
> }
>
> have you ever seen such code? I haven't.
It doesn't really matter if one of us has seen such code.
>
> if (!timed_wait(lk, xt, pred) ) {
> // handle timeout
> }
>
> is the norm (and pred is usually something lambda-ish).
I have no further objections to your proposed change. And I
will put this for the next release, as I am uncomfortably to
introduce this change in semantics for RC_1_34_0.
Also I would like to see yet other opinions on this matter.
Do you agree? If yes, it would be very nice if you could
file a feature request into source-forge, so that the issue
doesn't get lost.
> The low-level non-predicate version is available for those that are
> interested in the "raw" return value from the wait.
I agree, the wary user still has access to all information
by using the lower level primitives.
Roland