PTHREAD_CANCEL_HURD

[Thomas DiModica]

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.

There are interesting implications for this, however. pthread_join becomes a
function that may eat a signal to cancel. The main implication is, essentially,
that every occurrence of condition_wait becomes a call to hurd_condition_wait.
I don't know if any of the calls to condition_wait weren't cancellation points 
for
good reasons. Secondly, would this conflict with the proper functioning of the
libraries? Does a utility that links to a hurd library have to declare itself a
server to pthreads for the library to work properly (if the library expects 
these
cancellation semantics)?


This is just meant to look at and converse on.
Thomas D

PS. In timedwait, we dequeue the thread, but the cleanup handler (which is
always run) ensures that the thread is dequeued also. Is this necessary, or
just an artifact that is due to how all of the timed functions were implemented?

HurdInPthread.diff
Description: Text Data