Re: Hurd_condition_wait in glibc libpthreads in Debian

[Richard Braun]

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