This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Proposed fix for cancellation bug found by Neal Ferguson.
- To: Ulrich Drepper <drepper at cygnus dot com>
- Subject: Re: Proposed fix for cancellation bug found by Neal Ferguson.
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Tue, 26 Sep 2000 19:33:27 -0700 (PDT)
- cc: libc-alpha at sources dot redhat dot com
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.