Date: Thu, 10 Jan 2002 16:26:15 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: 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: <Pine.SUN.3.91.1020110161827.1485C-100000@pcnet1.pcnet.com> In-Reply-To: <3C3DF2D7.3FFF9D4A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jan 2002, Terry Lambert wrote: > Daniel Eischen wrote: > > > > Currently the kernel doesn't save the FPU state in the sigcontext, > > > > but it should. Wouldn't this solve the problem? > > > > > > What problem? > > > > > > Using FP code in signal handlers isn't legal. Why does everyone > > > want to do Bezier curves in signal handlers? > > > > It's not so you can do FP in signal handlers. You have to > > be able to resume the context passed to the signal handler > > at a later point in time. You are allowed to resume any > > context you want from the signal handler, but when you > > finally resume the context that was interrupted by the > > signal, then the FPU state had better be in the context. > > Type slowly, I'm old, and oother people on this list are older... > > What problem? > > If signal code doesn't touch the FPU statem then it's totally > transparent to the lazy save of FPU context state. OK, so the signal handler saves the interrupted context and resumes/starts another context. With me so far? Perhaps a few contexts later, and perhaps even a few signals later, and after doing some additional floating point stuff, the originally interrupted context is resumed. If the FPU state as it existed when it was interrupted is not in the context, then the FPU state will not be correctly restored. The FPU state as it exists when the context is restored is not necessarily the FPU state as when the context was interrupted. > 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? No, see above. You are not required to trampoline out of the signal handler. It is perfectly valid to use siglongjmp or setcontext to leave a signal handler (and the context that you return to does not have to be the interrupted context). > 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? I think I answered this, right? -- 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.1020110161827.1485C-100000>