Date: Thu, 5 Feb 2004 15:14:26 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> 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.GSO.4.10.10402051507260.16695-100000@pcnet5.pcnet.com> In-Reply-To: <63035.1076001842@thrush.ravenbrook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402051507260.16695-100000>