Re: Proposed fix for cancellation bug found by Neal Ferguson.

[Kaz Kylheku <kaz at ashi dot footprints dot net>]

On 26 Sep 2000, Ulrich Drepper wrote:

> Date: 26 Sep 2000 19:00:40 -0700
> From: Ulrich Drepper <drepper@redhat.com>
> Reply-To: Ulrich Drepper <drepper@cygnus.com>
> To: Kaz Kylheku <kaz@ashi.footprints.net>
> Cc: libc-alpha@sources.redhat.com
> Subject: Re: Proposed fix for cancellation bug found by Neal Ferguson.
> 
> Kaz Kylheku <kaz@ashi.footprints.net> writes:
> 
> > It happens *always* whenever a thread disables its cancellation and
> > then executes waits during which someone calls pthread_cancel on
> > it. E.g.  create a thread, have it disable cancellation and call
> > pthread_join(), then cancel that thread.  Spurious wakeup.  No
> > signals involved.
> 
> Well, this is one thing I asked myself when looking at the code.  Why
> isn't pthread_cancel simply returning if the cancelation state of the
> thread is PTHREAD_CANCEL_DISABLE?  It seems to make no sense to not to
> this test.

Because the test is delegated to the target thread, which allows its result
to jive with the cancellation state. If the canceller makes the test,
it opens the door for races, like: 

	target				canceller

					1. tests target for cancellation
	2. disables cancellation
	3. calls some cancellation 
	   point wait.
					4. goes ahead and cancels target
	5. experiences cancellation?

Of course, you can make it work if 1 and 4 are atomic with respect to 2.