>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
