Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-10-30 15:58:59

At 10:24 AM 10/30/2001, williamkempf_at_[hidden] wrote:
>I don't have access to the standard, but according to Butenhof's book
>this would be a bug in the pthreads implementation. None of the
>allowed error conditions can be returned because of this case (BTW,
>does 22 work out to be EINVAL?). The description of the semantics
>REQUIRE a call to pthread_cond_wait() or pthread_cond_timedwait() to
>block until either the condition is signaled OR until the operation
>times out in the case of pthread_cond_timedwait(). So the
>implementation should not be allowed to prematurely return because it
>detects that there's no way for the condition to become signaled. So
>I'm not convinced that this is why the assertion is occurring.

If it is any help, the Sun docs are available online. See

I put "POSIX Threads" into the search engine on that page and got 43
lists possible errors from condition variable related calls as:

These functions may fail if:
cond , attr , cvp , arg , abstime , or mutex point to an illegal address.
Invalid argument. For cond_init() , type is not a recognized type. For
cond_timedwait() , the specified number of seconds, abstime , is greater
than current_time + 100,000,000 , where current_time is the current time,
or the number of nanoseconds is greater than or equal to 1,000,000,000 .
The cond_timedwait() function may fail if:
The time specified by abstime has passed.


Boost list run by bdawes at, gregod at, cpdaniel at, john at