Alfred Perlstein wrote:
> * Dan Eischen <[EMAIL PROTECTED]> [011204 06:26] wrote:
> >
> > There are already cancellation tests when resuming threads
> > whose contexts are not saved as a result of a signal interrupt
> > (ctxtype != CTX_UC). You shouldn't test for cancellation when
> > ctxtype == CTX_UC because you are running on the scheduler
> > stack, not the threads stack.
> That makes sense, but why?

Because when a thread gets cancelled, pthread_exit gets called
which then calls the scheduler again.  It is also possible to
get interrupted during this process and the threads context
(which is operating on the scheduler stack) could get saved.
The scheduler could get entered again, and if the thread
gets resumed, it'll longjmp to the saved context which is the
scheduler stack (and which was just trashed by entering the
scheduler again).

It is too confusing to try to handle conditions like this, and
the threads library doesn't need to get any more confusing ;-)
Once the scheduler is entered, no pthread routines should
be called and the scheduler should not be recursively
entered.  The only way out of the scheduler should be a
longjmp or sigreturn to a saved threads context.

> >                                  You also have a bug in the
> > way you changed the check for cancellation flags.
> What?

When a thread is at a cancellation point, you want to let the
cancellable routine handle the cancel.  The check as coded before
avoided calling pthread_testcancel() when at a cancellation
point.  I think you check for either PTHREAD_AT_CANCEL_POINT
or PTHREAD_CANCEL_ASYNCHRONOUS being set when you really want
((flags & PTHREAD_AT_CANCEL_POINT) == 0) &&

> > There only clean way to fix this is to add a return frame
> > to the interrupted context so that it can check for cancellation
> > (and other things) before returning to the threads interrupted
> > context.
> No way to work around this?  Shouldn't the thread exit library
> know which stack exactly to clean up even in the context of a
> signal handler?

It assumes that you're running on the current threads stack.

I don't view this particular bug as a big problem.  It is a
somewhat perverse program that has a CPU bound thread that
never gets to any sort of blocking condition and yet still
wants to be cancelled.  The submitter of the problem doesn't
even want to upgrade to get a fix.  It can be worked around
easily enough by checking for cancellation or by using
pthread_kill to send a signal to the thread and have the
signal handler exit the thread or longjmp back to the thread
at a place that can exit and cleanup.

There is already a minor race condition in trying to resume
a thread that was interrupted by a signal.  Adding some code
to munge the stack of an interrupted context so that it calls
a wrapper function would solve both problems.  The signal
handling code already does this to install a signal handler
wrapper on a threads stack.

Dan Eischen

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to