From owner-freebsd-threads@FreeBSD.ORG Wed Feb 4 14:56:28 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 37D3216A4CE; Wed, 4 Feb 2004 14:56:28 -0800 (PST) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 082A543D2F; Wed, 4 Feb 2004 14:56:06 -0800 (PST) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([24.7.73.28]) by comcast.net (sccrmhc13) with ESMTP id <2004020422560401600147i3e>; Wed, 4 Feb 2004 22:56:05 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id OAA05163; Wed, 4 Feb 2004 14:56:02 -0800 (PST) Date: Wed, 4 Feb 2004 14:56:01 -0800 (PST) From: Julian Elischer To: Nick Barnes In-Reply-To: <58305.1075934936@thrush.ravenbrook.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Daniel Eischen 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: Wed, 04 Feb 2004 22:56:28 -0000 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" >