From owner-freebsd-threads@FreeBSD.ORG Fri Feb 6 10:37:00 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 4F8FD16A4CE for ; Fri, 6 Feb 2004 10:37:00 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A5E943D46 for ; Fri, 6 Feb 2004 10:36:58 -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 i16H9hfo019072; Fri, 6 Feb 2004 12:09:43 -0500 (EST) Date: Fri, 6 Feb 2004 12:09:43 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: John Polstra In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: Fri, 06 Feb 2004 18:37:00 -0000 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