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

[Daniel Eischen]

On Wed, 4 Feb 2004, Julian Elischer wrote:
> 
> On Wed, 4 Feb 2004, Nick Barnes wrote:
> 
> > 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);
> > 
> 
> Hmmmm looks to me like this may be easier to achieve than 
> to have horrible hacks depending on signal behaviour..
> 
> You could even have: "suspend_all_but_me()" which would block
> until all threads were suspended.
> threads in the kernel would return and immediatly suspend..
> (an upcall would be forced for their return)
> Note: we already have a lot of this in the debugger suppor that david Xu
> is working on.. 

See pthread_resume_all_np(3), pthread_resume_np(3), pthread_suspend_all(3),
and pthread_suspend_allnp(3) :-)  This is what the native JDK uses for
GC.

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

-- 
Dan Eischen