On Thu, Aug 02, 2012 at 03:13:12PM -0700, Thomas DiModica wrote:
> 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.
That's it.
> You mean like a PTHREAD_CANCEL_GNU? It would be
>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 t
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
> >cancelle
>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
On Wed, Aug 01, 2012 at 08:44:20AM -0700, Thomas DiModica wrote:
> Most of what I understand is from what Marcus has to say in this thread here:
> http://lists.gnu.org/archive/html/hurd-devel/2002-07/msg00010.html
That link explains the problem very well. It's better to keep the
current calls to h
From: Richard Braun
To: Thomas DiModica
Cc: "debian-h...@lists.debian.org" ;
"bdefre...@debian.org"
Sent: Tuesday, July 31, 2012 4:48 PM
Subject: Re: Hurd_condition_wait in glibc libpthreads in Debian
On Tue, Jul 31, 2012 at 03:16:05PM -0700, Thomas DiModica wrote:
> A
