On Wed, Aug 01, 2012 at 06:40:05PM -0700, Thomas DiModica wrote: > > > >No, the semantics are the same. The internal implementation may slightly > >differ, I haven't looked in detail. The point is how to handle > >cancellation from a cancelled thread, not how to mark a thread as being > >cancelled. The hurd_thread_cancel function merely exists because there > >isn't any in the cthreads package. You should be able to replace it with > >pthread_cancel without further effort. > > >-- > >Richard Braun > > I don't think that the semantics are the same. From what I can tell, > hurd_thread_cancel kindly informs the thread that it has been canceled > and should take an appropriate action, while pthread_cancel has the > thread call pthread_exit at the next cancellation point. How they mark a > thread as canceled differs too: hurd cancellation is flagged within the > thread's struct hurd_sigstate, while pthread cancellation is flagged > within the thread's struct __pthread.
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". The difference, again, is in how cancellation requests are handled by a thread noticing it has been cancelled (don't even consider asynchronous cancellation in the Hurd). And as I said earlier, even if the implementation varies, it does only slightly, as you confirmed it. The only relevance of this difference is for the new hurd_condition_wait function, obviously. > Here is the declaration of hurd_thread_cancel from glibc's hurd.h: > /* Cancel pending operations on THREAD. If it is doing an interruptible RPC, > that RPC will now return EINTR; otherwise, the "cancelled" flag will be > set, causing the next `hurd_check_cancel' call to return nonzero or the > next interruptible RPC to return EINTR (whichever is called first). */ > extern error_t hurd_thread_cancel (thread_t thread); 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. -- Richard Braun [1] http://pubs.opengroup.org/onlinepubs/009696799/functions/pthread_cancel.html
