Re: Hurd_condition_wait in glibc libpthreads in Debian

[Thomas DiModica]

>No, the semantics are the same. And you're saying it yourself :
>"hurd_thread_cancel kindly informs the thread that it has been
>canceled". The description of pthread_cancel is "The pthread_cancel()
>function shall request that thread be canceled. [...] The cancellation
>processing in the target thread shall run asynchronously with respect
>to the calling thread returning from pthread_cancel()." [1]. The Linux
>man page goes as far as to say "pthread_cancel - send a cancellation
>request to a thread".

I get what you're saying: I'm confusing the semantics of how cancellation
is HANDLED with the semantics of how it is SIGNALED. The signaling
semantics are the same.

>It should probably be replaced with pthread_cancel completely, since
>they do the same thing. The difficulty will be adjusting the Hurd so
>that the server threads never stop because of an unexpected cancellation
>point. One way that comes to my mind is to disable cancellation by
>default in Hurd server threads, and making pthread_cancel ignore that
>state (i.e. still mark such threads as being cancelled). Normal
>cancellation points will simply ignore those requests, whereas
>hurd_condition_wait will report it. For more clarity, you could
>introduce a Hurd-specific cancellation state/type with that effect.

You mean like a PTHREAD_CANCEL_GNU? It would be doable.
If that were the case, we could merge hurd_condition_wait into
phread_cond_wait as a special case. Maybe: streamio
intermingles the two, pflocal did.
That would also handle hurd_check_cancel.

I'm sorry everyone for the emails.
I had to think a little for his point to set it.

The important part is having a function that handles cancellation
like cthreads did in libpthread, so that the Hurd can be moved to it.

Thomas D