From owner-freebsd-threads@FreeBSD.ORG Thu Feb 5 14:35:40 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 067FD16A4CE for ; Thu, 5 Feb 2004 14:35:40 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D4CA43D5E for ; Thu, 5 Feb 2004 14:35:37 -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 i15KEQfo026482; Thu, 5 Feb 2004 15:14:26 -0500 (EST) Date: Thu, 5 Feb 2004 15:14:26 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Nick Barnes In-Reply-To: <63035.1076001842@thrush.ravenbrook.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Julian Elischer 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 22:35:40 -0000 On Thu, 5 Feb 2004, Nick Barnes wrote: > At 2004-02-05 14:27:37+0000, Daniel Eischen writes: > > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > > > At 2004-02-05 01:03:43+0000, Daniel Eischen writes: > > > > > > > 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. > > > > > > Way cool. Can I get the context (i.e. registers) of a suspended thread? > > > > No, you can get the thread attributes which include the stack base > > and addr, see pthread_attr_get_np(3). The JDK seems to make do > > without getting suspended thread context. > > Somehow the GC must see the registers of each suspended thread, so > that it can preserve any objects to which the registers point. > Presumably the thread context is stored in some region which the GC > treats as a root (e.g. on the thread stack, identified with > pthread_attr_get_np, as you say). > > A GC which has more information (e.g. the IP, the SP) may be able to > use more sophisticated techniques (by using compiler-generated object > liveness information, or by excluding dead areas of a stack segment > from consideration as roots). The limit of this is a system with > close-coupled compiler, thread system, and GC, which can do "precise > collection", including modifying the values of registers and stack > slots. I hear what you are saying, but it would seem that better designed software would avoid the issue by keeping track of any objects a thread has, using pthread_cleanup_push/pop, mutexes, etc. FWIW, the Ada tasking run-time used by GNAT has no such need to use pthread_suspend/resume and look at thread contexts. I don't know too much about the native JDK (1.4) but it seems to get by with suspend/resume and without needing to look at the thread contexts. The older JDK 1.3 did need to do that, though. -- Dan Eischen