Date: 2001-10-30 16:04:10
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 10:24 AM 10/30/2001, williamkempf_at_h... wrote:
> >I don't have access to the standard, but according to Butenhof's
> >this would be a bug in the pthreads implementation. None of the
> >allowed error conditions can be returned because of this case
> >does 22 work out to be EINVAL?). The description of the semantics
> >REQUIRE a call to pthread_cond_wait() or pthread_cond_timedwait()
> >block until either the condition is signaled OR until the
> >times out in the case of pthread_cond_timedwait(). So the
> >implementation should not be allowed to prematurely return
> >detects that there's no way for the condition to become
> >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
> 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
Butenhof doesn't list this one, but it wouldn't apply to this case
> Invalid argument. For cond_init() , type is not a recognized type.
> cond_timedwait() , the specified number of seconds, abstime , is
> than current_time + 100,000,000 , where current_time is the current
> or the number of nanoseconds is greater than or equal to
The reasons Butenhof lists for EINVAL are the following:
1) cond, mutex, or abstime is invalid (basically the only reason
2) different mutexes for concurrent waits
3) mutex is not owned by calling thread
None of these apply to our case either.
> The cond_timedwait() function may fail if:
> The time specified by abstime has passed.
Butenhoff lists this as ETIMEDOUT not ETIME, and this is the error
the code expects to get back.
It would help if someone can determine precisely what error is being
returned here (in the name format instead of the integer equivalent).
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk