Re: PTHREAD_CANCEL_HURD

[Roland McGrath]

> How would that make Hurd servers behave ? Would client receive the
> ECANCELED error ? Isn't it better to just completely ignore the
> cancellation everywhere except where hurd_condition_wait is called, as
> it is done currently ?

That's certainly not what's done currently.  hurd_thread_cancel causes
all "interruptible" RPC stubs to return EINTR, either by preventing
the RPC from being made or by sending interrupt_operation RPCs to
servers.  This is the effect of the INTR_INTERFACE macro that appears
in hurd/*.defs.  (See libc/hurd/intr-msg.c, _hurdsig_abort_rpcs, etc.)
This is the moral equivalent to the POSIX calls that are cancellation
points.  (The Hurd code predates the specification of pthreads by a
few years, but it was designed according to the same concept of
cancellation that lead to that part of the pthreads specification.)

> > I'd call this new type by a name that's descriptive of what it means,
> > rather than what programs are expected to use it.  For example,
> > PTHREAD_CANCEL_POLLED.
> 
> Could it hurt portability (not that I know of any other system using
> glibc that uses such tricks, but still) ?

I can't really imagine what issue you have in mind.  To fit with the
convention in NPTL for extensions, it should be PTHREAD_CANCEL_POLLED_NP.
(The "_NP" suffix indicates it's a non-POSIX feature.)

Thanks,
Roland