From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-30 17:27:11
Hi,
A little bit more information. Assert firing while processing check
in line 131, for the test_timedlock<mutex>(). All other top level
tests does not affect it. The only nuance is that now error became
not stable what means that assert fired only sometimes. Ant ideas? If
I will have time I will try to play more with it.
Gennadiy.
P.S. EINVAL Source:
EINVAL
The value specified by cond, mutex, or abstime is
invalid.
EINVAL
Different mutexes were supplied for concurrent
pthread_cond_wait() or pthread_cond_timedwait() opera-
tions on the same condition variable.
EINVAL
The mutex was not owned by the current thread at the
time of the call.
--- In boost_at_y..., williamkempf_at_h... wrote:
> --- In boost_at_y..., "Gennadiy E. Rozental" <rogeeff_at_m...> wrote:
> > EINVAL
> >
> > > It would help if someone can determine precisely what error is
> > being
> > > returned here (in the name format instead of the integer
> > equivalent).
> > >
> > > Bill Kempf
>
> OK, that's a starting point. Unfortunately, I don't see how any of
> the parameters can be considered invalid. Especially since this
same
> code works on other POSIX/pthread platforms.
>
> Let's try and assume that the guess about the implementation
figuring
> out there are no other running threads to signal the condition is
the
> culprit. Can someone on Solaris modify the code such that a dummy
> thread is created that simply sleeps for twice as long as we
> timeout? This should help to eliminate this guess as the culprit.
>
> Bill Kempf