Date: 2001-10-30 10:24:55
--- In boost_at_y..., John Maddock <John_Maddock_at_c...> wrote:
> >Sorry, I must be dense. Both issues? I see two issues below:
> >pthread_cond_wait() returning 0 instead of an error for timeout
> >pthread_equal() not working. If -mt fixes both of these then what
> >exactly is asserting?
> OK, with sunpro, you see the failed assertion (and you have to use -
> otherwise the thread lib doesn't compile).
> With gcc there is a -pthreads option, but I see std lib related
> errors if I use this (there appear to be no std exception
> If I use:
> g++ -I../../ sources -lrt
> Then I see the errors I reported, but with:
> g++ -I../../ src/*.cpp test/*.cpp -lrt -lpthread
> Then I see the same behaviour as with sunpro. Looks like the
runtime has a
> stub non-functioning pthreads lib in it, and you need to link to
> -lpthread to get the correct behaviour.
Strange, but believable. Are you compiling through Jam or setting up
your own build system on these platforms? If it's with Jam then it
sounds like we need to patch the toolsets in question.
> The cause is the same - you are waiting on a condition variable
> is only one thread - the thread scheduler knows that the condition
> never be signalled, and so gives up.
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk