bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext

[Nick Barnes]

At 2004-02-04 15:51:53+0000, Daniel Eischen writes:

> Still it iw worth noting that trying to do anything sane with
> a context from a pthread_kill() is probably not what you want
> especially for scope process threads.

Thanks for this note.  FYI, using the context in a handler from a
pthread_kill signal is standard practice for garbage collecting
threaded applications: the threads need to be paused while their
stacks and registers are scanned by the garbage collector; this is
done by sending signals to each thread (apart from the GC thread).
The signal handler saves the thread's context, notifies the GC thread,
and then waits to be awoken (e.g. with sigsuspend).

What memory management implementors would really like is for thread
library implementors to abstract away the messy implementation details
of this and to provide something like this:

          int pthread_suspend(pthread_t thread,
                              ucontext_t *uap);

          int pthread_resume(pthread_t thread,
                             ucontext_t *uap);

I believe that various people argued for this when the pthreads
standard was being put together.  But it never happened, and we have
been stuck with techniques such as the one I describe.  I've
implemented things like it for several different garbage collectors on
a number of thread libraries, pthread and otherwise, on Windows (where
there _is_ SuspendThread and ResumeThread) and a number of Unixes.  I
will be glad to be able to support multi-threaded applications on
FreeBSD - my desktop OS - as well.

Nick B