[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Hurd_condition_wait in glibc libpthreads in Debian
From: |
Thomas DiModica |
Subject: |
Re: Hurd_condition_wait in glibc libpthreads in Debian |
Date: |
Thu, 2 Aug 2012 15:13:12 -0700 (PDT) |
>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