Re: thread lib: solaris problems.

From: williamkempf_at_[hidden]
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 
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 
> http://docs.sun.com/
> 
> I put "POSIX Threads" into the search engine on that page and got 
43 
> matches.
> 
> http://docs.sun.com/ab2/coll.40.6/REFMAN3D/@Ab2PageView/8054?
DwebQuery=POSIX+OR+Threads&oqt=POSIX+Threads&Ab2Lang=C&Ab2Enc=iso-
8859-1#REFSECT_3 
> lists possible errors from condition variable related calls as:
> 
> These functions may fail if:
> EFAULT
> cond , attr , cvp , arg , abstime , or mutex point to an illegal 
address.

Butenhof doesn't list this one, but it wouldn't apply to this case 
any way.

> EINVAL
> 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 reasons Butenhof lists for EINVAL are the following:

1) cond, mutex, or abstime is invalid (basically the only reason 
given above)
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:
> ETIME
> 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).

Bill Kempf