Re: PTHREAD_CANCEL_HURD

[Thomas DiModica]

Sometimes, I ask questions early, without thinking for myself of the answers:


>> PS. In timedwait, we dequeue the thread, but the cleanup handler (which is
>> always run) ensures that the thread is dequeued also. Is this necessary, or
>> just an artifact that is due to how all of the timed functions were 
>> implemented?

>The timing of your question is interesting. My current work on fixing
>select has led me to introduce a hurd_condition_timedwait function in
>the cthreads library. It prove more difficult than I initially expected
>precisely because of the issues around the condition queue (they also
>apply to pthread_mutex_timedlock). In short, this is a bug. You can take
>a look at my work directly on the Hurd repository.

I understand now: we want to immediately dequeue ourselves, even if it means
wasting cycles later by checking to ensure that we were dequeued. The last
thing we want is to return ETIMEDOUT when another thread has intervened,
and deququed us to wake for a condition_signal. But... why are we using the
mutex's lock, if we're queued on the condition? That's the bug.

Thomas D