Date: Wed, 4 Feb 2004 20:03:43 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Julian Elischer <julian@elischer.org> Cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Message-ID: <Pine.GSO.4.10.10402041958470.22525-100000@pcnet5.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0402041452150.4641-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402041958470.22525-100000>