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

[Julian Elischer]

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

> 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
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to "freebsd-threads-unsubscribe at freebsd.org"
>