Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 4 Feb 2004 14:56:01 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        Nick Barnes <Nick.Barnes@pobox.com>
Cc:        freebsd-threads@FreeBSD.org
Subject:   Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext 
Message-ID:  <Pine.BSF.4.21.0402041452150.4641-100000@InterJet.elischer.org>
In-Reply-To: <58305.1075934936@thrush.ravenbrook.com>

next in thread | previous in thread | raw e-mail | index | archive | help


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0402041452150.4641-100000>