Date: Mon, 20 Nov 1995 13:20:45 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: cimaxp1!jb@werple.net.au (John Birrell) Cc: bde@zeta.org.au, hackers@FreeBSD.ORG, jb@cimlogic.com.au Subject: Re: int type in jmpbuf Message-ID: <199511202020.NAA01872@phaeton.artisoft.com> In-Reply-To: <199511200005.LAA25969@werple.net.au> from "John Birrell" at Nov 20, 95 11:08:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >You should copy setjmp.S > >and adapt it. Note that it isn't possible to do preemptive context > >switching for threads using only setjmp() - setjmp() doesn't preserve > >all of the floating point state in FreeBSD. > > I don't agree with this. gcc under FreeBSD appears to re-load floating > point "registers" after a function call (like setjmp). This means that > setjmp/longjmp don't need to save the floating point state. > > When a signal occurs, though, the floating point state is not saved. > [We think it should be saved. Is there anything that says that floating > point calculations in a signal handler can ruin your whole day?! 8-)]. > This is true of FreeBSD and NetBSD/i386, but it is _not_ true of > NetBSD/Alpha which saves floating point registers routinely. > > Preemptive context switching in user-space threads under FreeBSD needs to > save the floating point state when entering the scheduler from the signal > handler. Before calling sigreturn to re-start an interrupted thread (as > opposed to one that was simply context switched using setjmp), the floating > point state is restored. This means that the behavio[u]r of a signal handler > under a threaded program will not corrupt the floating point state of a > program as it will with a non-threaded program. What is a signal? A signal is a persistent condition. A signal is *NOT* an event. Doing anything other than setting a flag that gets checked later (unless you are going to never return from the handler) is bogus programming in the extreme. For preemptive context switching with LWP in Sun's user space thread environment (which uses async I/O instead of signal-based scheduling), there is a system call to save and restore register state. You are assuming that a signal is an event in using it for your scheduler and are in fact screwing up as a result. Lazy switching of FP register is one of the big optimization wins for context switching, even if you don't rewrite the active pte: ie: user space sontext switching without changing process context. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511202020.NAA01872>