Date: Thu, 10 Jan 2002 13:33:46 -0700 From: Nate Williams <nate@yogotech.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Daniel Eischen <eischen@pcnet1.pcnet.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Nate Williams <nate@yogotech.com>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <15421.64170.308581.606485@caddis.yogotech.com> In-Reply-To: <3C3DF2D7.3FFF9D4A@mindspring.com> References: <Pine.SUN.3.91.1020110143509.987C-100000@pcnet1.pcnet.com> <3C3DF2D7.3FFF9D4A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15421.64170.308581.606485>