Date: Thu, 05 Feb 2004 20:48:46 +0000 From: Nick Barnes <Nick.Barnes@pobox.com> To: Daniel Eischen <eischen@vigrid.com> Cc: freebsd-threads@FreeBSD.org Subject: Re: bin/31661: pthread_kill signal handler doesn't get sigcontext or ucontext Message-ID: <63562.1076014126@thrush.ravenbrook.com> In-Reply-To: <Pine.GSO.4.10.10402051507260.16695-100000@pcnet5.pcnet.com> from Daniel Eischen <eischen@vigrid.com> of "Thu, 05 Feb 2004 15:14:26 -0500"
next in thread | previous in thread | raw e-mail | index | archive | help
At 2004-02-05 20:14:26+0000, Daniel Eischen writes: > 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. This is an argument about the utility of garbage collection in general (or possibly about the utility of threads). That subject has been done to death many times; let's not restart it here. > FWIW, the Ada tasking run-time used by GNAT has no such need > to use pthread_suspend/resume and look at thread contexts. Fascinating. Maybe I should take a look at it. If you have a sufficiently cooperative compiler then many of these tricks are not necessary. In particular, if the stack and register management code generated by your compiler (stack frame creation and teardown, register spill, reload, stack allocation, thread context switching, etc) cooperates with the garbage collector, then there may be no need even to suspend threads (e.g. if you can guarantee that any pointer in a register is also on the stack or another object, and avoid the obvious race conditions somehow). Interpreted systems (including bytecoded languages) are also easy to make much more GC-cooperative. > 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. I am certainly interested in the JDK techniques; I shall investigate further. Possibly the JDK knows where or how the thread contexts are allocated, and treats such memory as a conservative root. I guess we're about done on freebsd-threads. I'll move over to freebsd-java to ask about the JDKs. Thanks again for all your advice. Nick B
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?63562.1076014126>