Subj : Re: thread control by mutex, predicates and conditions puzzle
To   : comp.programming.threads
From : Joseph Seigh
Date : Sat Jan 08 2005 08:17 am

On 8 Jan 2005 03:36:47 -0800, Jomu <dragisha@gmail.com> wrote:

> Joseph Seigh wrote:
>> On 7 Jan 2005 10:15:32 -0800, Jomu <dragisha@gmail.com> wrote:
>>
>> > There are signals which will get you out of pthread_cond_wait,
> probably
>> > all (I can't recall any exceptions). Your thread waiting on
> condition
>> > will get EINTR as result of pthread_cond_wait and there you can
> handle
>> > situtation. Of course, signal itself is supposed to be handled in
> it's
>> > handler and after getting EINTR it is up to your thread to lookup
> state
>> > changed by that handler.
>>
>> Most implementations will handle EINTR as a spurious wakeup but you
>> cannot depend on that behavior.  The implementation is allowed to go
>> back into wait.
>>

> I do not expect pthread_cond_wait (or any other blocked operation,
> where other operations are as needed to be covered as pthread_*) to
> return anything, I just sigwait() in signal handler for "resume"
> signal. For this signal, I use pthread_kill(), of course.
>
>

pthread_cond_wait does not return EINTR under any circumstances.
pthread_cond_wait is not required to do anything upon receipt of
a unix signal during wait.  It can continue waiting or it can
return as a spurious wakeup entirely at the choice at the implementation.

You comment about sigwait is a non sequitur and has nothing to
do with pthread_cond_wait.  You shouldn't top post.  Not only
is it annoying but you managed to confuse yourself.  Go back
as read your previous comment about signals getting you out
of pthread_cond_wait.  It's quoted at the top of this post if
you've forgotten.

Joe Seigh

Joe Seigh

.