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>