Date: Fri, 6 Feb 2004 12:09:43 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: John Polstra <jdp@polstra.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.10402061200100.16647-100000@pcnet5.pcnet.com> In-Reply-To: <XFMail.20040206085720.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 Feb 2004, John Polstra wrote: > On 05-Feb-2004 Daniel Eischen wrote: > > On Thu, 5 Feb 2004, Nick Barnes wrote: > > > >> 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. > > Maybe so, but that's not a useful attitude for an OS vendor to take. > An operating system is a provider of services. The services it > provides had better be generally useful, or people will make other > choices. > > Like it or not, a lot of GC systems these days are built on legacy > compilers (often GCC) that are not very malleable. They can't GNAT is built on GCC and uses native threads. It has been built onto GCC since 2.7.x (and probably prior). > easily be made to do the bookkeeping you're asking for. Or even if > they could do that, they call into legacy libraries (such as libc) > that were not compiled with such bookkeeping in mind. JDK is the > exception, not the rule. It is the way it is because Sun, IBM and > other companies have poured zillions of dollars into it. > > If FreeBSD's native threads package can't provide a way to suspend > all threads except the GC thread and then read the registers of the > suspended threads, then the very widely-used Boehm conservative GC > package won't be usable with FreeBSD's native threads. Likewise, To date, no-one has asked for the ability to read a suspended threads registers. With libpthread, you can get the thread context via pthread_kill() which is what the PR was written against. I don't know whether you can do anything useful with that context since it can be made via signalcontext(libc). > those limitations would make it impossible to adapt Modula-3's threads > package to take advantage of FreeBSD native threads -- which would > be a big win performancewise. I'm sure there are plenty of other > examples. Well, we are implementing POSIX API's so if there is an existing standard for pthread_get_suspended_thread_context(), we'll add it. Or if there is some de-facto standard that other vendors seem to be implementing we can do that. I've even made the offer to the -java folks to add whatever they need to get the JDK to work, and so far all they really needed was suspend/resume and a way to get thread attributes (stack). -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402061200100.16647-100000>