Date: Mon, 7 Jan 2002 15:59:14 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Nate Williams <nate@yogotech.com> Cc: Nate Williams <nate@yogotech.com>, Dan Eischen <eischen@vigrid.com>, Peter Wemm <peter@wemm.org>, Archie Cobbs <archie@dellroad.org>, Alfred Perlstein <bright@mu.org>, arch@FreeBSD.ORG Subject: Re: Request for review: getcontext, setcontext, etc Message-ID: <Pine.SUN.3.91.1020107155415.22099A-100000@pcnet1.pcnet.com> In-Reply-To: <15418.2505.568006.160724@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jan 2002, Nate Williams wrote: > > > Here is some code snippets on that note. (It's been a *LONG* time since > > > I looked at this, so be nice to me. :) > > > > > > Basically, we do a 'fsave' on an 108 byte array (which is the amount of > > > space required to save a complete processor state of the FPU unit on a > > > 387), and then later restore the same state. > > > > Ok, but are you sure that the FP state isn't being saved > > because it also has to handle restoring thread contexts > > interrupted by signals? I noticed it was using siglongjmp... > > Again, it's been a long time since this was done. We may be inefficient > in some cases (saving the context twice), but I do know that w/out the > fsave/frstr code, threads that did FPU operations ended up with *really* > funky answers, and FPU errors were never caught correctly. > > > If you have a call to a function in the middle of doing > > some FP stuff, that function itself could do a slew of > > other FP calculations: > > > > /* FP munch */ > > foo_fp_munch_lots_more(); > > /* FP munch some more */ > > > > What guarantees do you have that the FP state is restored > > to where it was prior to calling foo_fp_munch_lots_more()? > > Because the code (and code similar to it) is called by the thread > scheduler when a thread switches context. > > Above, if the thread switches context (involuntarily or voluntarily), > the code I posted (and others routines similar to it it) also saves the > context, and just before the context is switched back to the above > thread, the FPU context is restored (along with all of the other > information necessary to restore the thread context). > > Not all thread switches are done using yield. I am only concerned with voluntary switches; forget about signals and preemptions. The threads library knows the difference between voluntary and involuntary switches. Involuntary switches always come from the kernel (in libc_r via signals) and have the full FPU state saved (and restored when resumed). Assume that setcontext can tell if the FP state is saved or not and will restore it when needed. Assume that the kernel (or the threads library) will save the FP state when a signal occurs. -- Dan Eischen 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?Pine.SUN.3.91.1020107155415.22099A-100000>