From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 17:03:53 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0964C16A4CE for ; Wed, 4 Feb 2004 17:03:53 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77E2043D46 for ; Wed, 4 Feb 2004 17:03:51 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1513hfo023818; Wed, 4 Feb 2004 20:03:44 -0500 (EST) Date: Wed, 4 Feb 2004 20:03:43 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Julian Elischer In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Nick Barnes cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2004 01:03:53 -0000 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