Re: PTHREAD_CANCEL_HURD

[Richard Braun]

On Fri, Aug 03, 2012 at 12:20:09PM -0700, Thomas DiModica wrote:
> I was thinking about what Richard Braun said about removing 
> hurd_thread_cancel.
> Attached is an exploration into implementing PTHREAD_CANCEL_HURD as a
> cancellation state extension. It compiles, but I haven't tested if the 
> resulting library
> still works.
> 
> A server would call pthread_hurd_server_np upon start-up, which irreversibly 
> puts
> pthreads into hurd_server mode. All this really does is set the default 
> cancellation
> state for new threads to be the new cancellation state. The function
> pthread_check_and_clear_cancel_np replaces hurd_check_cancel. The name is
> more verbose, but describes what the function does. pthread_testcancel doesn't
> return a value and I didn't want to change that. Disgustingly, I've reused
> state_lock to act as the lock for cancel_pending, so we don't accidentally 
> lose
> any signals to cancel.

After some thinking, I don't think adding the new Hurd-specific calls is
a good thing. For one, having libports set the appropriate state is very
easy. Although I doubt it, we could imagine some servers might actually
use pthread cancellation the standard way (e.g. ported FUSE servers), so
making it the default for all threads doesn't sound good. And as I told
you privately, making it explicit (for custom threads, not libports
ones) is better for readability.

I'd say pthread_testcancel_np, returning a simple int, would be a better
name for the replacement of hurd_check_cancel. I suppose (but haven't
checked thoroughly) that holding the state_lock is mandatory and you
shouldn't feel disgust at having reused it.

-- 
Richard Braun