From owner-freebsd-arch Thu Jan 10 12:34:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id B48E937B417 for ; Thu, 10 Jan 2002 12:34:20 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id NAA03574; Thu, 10 Jan 2002 13:33:51 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id g0AKXkm24471; Thu, 10 Jan 2002 13:33:47 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15421.64170.308581.606485@caddis.yogotech.com> Date: Thu, 10 Jan 2002 13:33:46 -0700 To: Terry Lambert Cc: Daniel Eischen , Dan Eischen , Peter Wemm , Nate Williams , Archie Cobbs , Alfred Perlstein , arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc In-Reply-To: <3C3DF2D7.3FFF9D4A@mindspring.com> References: <3C3DF2D7.3FFF9D4A@mindspring.com> X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > So if I use the FPU, get context switched out, get sent a > signal, as long as any FPU state gets set back before I > trampoline out, everything's good, right? So far so good. > The lazy-bound > FPU state, which is per-process is exactly where the > process had it when it was switched out. So even if I'm > time sliced out because some idiot wrote a lot of code in > a signal handler because they didn't understand persistant > conditions vs. events, when I'm switched back to the code > in the signal handler, my FPU state is where it should be, > right? (Daniel, feel free to correct me where I'm wrong.) Wrong, because there are multiple threads per process, and each 'thread' in the process can be doing different things w/regard to the FPU state. However, if you use signals to do user-land thread switching, then having the signal handler will take care of userland context switching. Unfortunately, if the thread gives up it's context, there is no signal, and hence no FPU state is being saved, so it must be explicitly saved. > I guess I don't understand the circumstances under which > the FPU state could be wrong. See above. Even in 5.0, we're going to have some threads being switched in userland context, while others are switched in the kernel. (KSE is a hybrid approach that attempts to gain both the effeciency of userland threads with the ability to parallelize the effeciency gains of multiple CPU && I/O processing from kernel threads. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message