Re: PTHREAD_CANCEL_HURD

[Richard Braun]

On Fri, Aug 03, 2012 at 12:20:09PM -0700, Thomas DiModica wrote:
> 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)?

For any code unaware of this type, it would simply act as if
cancellation was disabled.

> 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?

The timing of your question is interesting. My current work on fixing
select has led me to introduce a hurd_condition_timedwait function in
the cthreads library. It prove more difficult than I initially expected
precisely because of the issues around the condition queue (they also
apply to pthread_mutex_timedlock). In short, this is a bug. You can take
a look at my work directly on the Hurd repository [1].

-- 
Richard Braun

[1] http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=rbraun/select_timeout