Date: Thu, 10 Jan 2002 12:00:23 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Daniel Eischen <eischen@pcnet1.pcnet.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: <3C3DF2D7.3FFF9D4A@mindspring.com> References: <Pine.SUN.3.91.1020110143509.987C-100000@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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? 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 guess I don't understand the circumstances under which the FPU state could be wrong. The only case I can think of is a "sigsched" approach, using longjmp in signal handlers to do really gross scheduling (comp.unix.sources, ca. 1983), and we already decided that such a system would need to do explicit saves and restores, if it wanted to use the FPU in multiple threads. Is this what we are talking about, resuming a different thread in a signal handler as part of the scheduler implementation? If so, this implies worse problems than those in this current discussion, when you go multi-threaded on multiple CPUs. Right now, there is an explicit save to ensure that being switched off a CPU after an exception but before it is signalled, then resumed on another CPU, while the previous CPU does not schedule any more code that uses the FPU, so a lazy exception raise can't work. I think we could still delay this (lazy bind it), by making migration an exceptional condition, but it's not a problem right now, is it? I mean, we aren't giving bad data to the SETI@Home people when using SMP systems, are we???? The way to handle it would be to mark FPU state for an immediate save on migration, if a lazy save has not been forced by the use of another FPU instruction in some other task, prior to the migration. I don't see this as being a user space/signal issue, though. -- Terry 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?3C3DF2D7.3FFF9D4A>