From owner-freebsd-threads@FreeBSD.ORG Thu Apr 10 22:55:33 2003 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 B38DF37B401; Thu, 10 Apr 2003 22:55:33 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1437B43FA3; Thu, 10 Apr 2003 22:55:33 -0700 (PDT) (envelope-from eischen@pcnet1.pcnet.com) Received: from pcnet1.pcnet.com (localhost [127.0.0.1]) by mail.pcnet.com (8.12.8/8.12.1) with ESMTP id h3B5tWBg025974; Fri, 11 Apr 2003 01:55:32 -0400 (EDT) Received: from localhost (eischen@localhost)h3B5tVjl025968; Fri, 11 Apr 2003 01:55:31 -0400 (EDT) Date: Fri, 11 Apr 2003 01:55:31 -0400 (EDT) From: Daniel Eischen To: David Xu In-Reply-To: <008001c2ffe8$056584f0$f001a8c0@davidw2k> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: patch for %gs saving 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, 11 Apr 2003 05:55:34 -0000 On Fri, 11 Apr 2003, David Xu wrote: > Here is the patch for kernel to save %gs, > it works well on my machine. > http://people.freebsd.org/~davidxu/i386_gs.diff Thanks, I'll give it a go. > Daniel, is this the reason in your libpthread > patch that doesn't use getcontext syscall ? No, we already had userland versions of getcontext() so I simply reused them to avoid the system call. That's why THR_GETCONTEXT is a macro; it can be defined to be getcontext() for those archs that don't have userland versions and want to use the system call instead. Note that we still need userland versions of _thread_switch() and _thread_enter_uts() anyways, so writing a userland [gs]etcontext() is probably pretty simple once you have those. Plus, when you get a context in order to make a context for a new thread, you still can't rely on %gs because it may be scheduled on another KSE or the thread could be a scope system thread in which case it be scheduled in another KSEG. So the current %gs isn't necessarily correct for a new thread. Hmm, this raises a good point. Once you set up a thread to run a signal handler, the %gs register has already been set. We have to be sure that the interrupted context and the thread's new (signal) context both have the same %gs and that it runs on the correct KSE. Either that, or we have to be able to change the contexts to be the correct %gs before running the thread and invoking the handler. -- Dan Eischen