[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PTHREAD_CANCEL_HURD
From: |
Thomas DiModica |
Subject: |
PTHREAD_CANCEL_HURD |
Date: |
Fri, 3 Aug 2012 12:20:09 -0700 (PDT) |
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
- PTHREAD_CANCEL_HURD,
Thomas DiModica <=
- Re: PTHREAD_CANCEL_HURD, Roland McGrath, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Roland McGrath, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Roland McGrath, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/11
- Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/11
Re: PTHREAD_CANCEL_HURD, Richard Braun, 2012/08/03