Date: Thu, 10 Jan 2002 16:45:13 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Nate Williams <nate@yogotech.com> Cc: Nate Williams <nate@yogotech.com>, Peter Wemm <peter@wemm.org>, Dan Eischen <eischen@vigrid.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.1020110162911.1485E-100000@pcnet1.pcnet.com> In-Reply-To: <15421.64556.613206.825107@caddis.yogotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 10 Jan 2002, Nate Williams wrote: > > To summarize a few things: > > > > o A trap will occur whenever you access the FPU > > Whenever you *acess* the FPU a trap occurs? I didn't realize this. I'm not too sure on this, but I think so after reading the code. bde will correct me if I'm wrong. > > , but this will > > occur only once while the process (or KSE) is executing. Once > > a process (KSE?) has the FPU, no other traps will occur until > > the process/KSE is swapped out and back in again. > > Unless you get an exception (div by zero, etc..), correct? > > > So traps > > are limited to once per process/KSE resumption. (And I mean > > "I don't have the FPU" traps, not other FPU traps.) > > Never mind. > > > This > > is true of i386, but is it true for other archs, or is the > > FPU state always restored for those archs? > > I'll let someone more clued than me respond. > > > o For non-threaded applications, getcontext and setcontext > > will always result in a system call (to get/set the signal > > mask). > > Ok, but we're now assuming that all threading models using libc_r. > There may be another threading implementation besides the one in libc_r, > so will it have the same functionality as the one in libc_r? (I guess > we could always copy the code from there...) The above was just to say that getcontext/setcontext use _sigprocmask to get and set the signal mask, and this results in a system call unless it is overridden (_sigprocmask is a weak symbol which another library like libc_r can override). > > o POSIX/SUSv2 mandate that the context passed out to a signal > > handler can be used in a setcontext() call. Other threads > > (or contexts) may be run after the signal and before resuming > > the context originally passed to the signal handler. This > > means that the FPU state must be contained in the context > > passed to the signal handler. > > The entire FPU state? I don't really know that. But there has to be enough FPU state so that it can be restored correctly. > > o The threads library or other application, may make many > > context switches before it is preempted. > > What do you mean by context switch in this case? My assumption up to > this point is that context switch is a thread of execution changing it's > context (be it either kernel threads of userland threads). Using that > definition, I'm assuming you mean pre-empted by the kernel doing a > process-switch (vs. a context switch) because the userland process has > used up it's timeslice. No, I mean application context switches (setcontext). Take a perverse case of two threads that do nothing but pthread_yield(). There will be many pthread_yields() before the kernel preempts the process. > > We also have sort of agreed that we only care about FPU state > > being in ucontext during signal delivery (in the KSE case, it > > will probably also need to be there when the thread/KSE is > > preempted). > > I haven't agreed. Bruce has stated this, but based on everything else > I've read (and the lack of details) we still need to save the entire FPU > state when signals are not used. (See the thread.yield() case). OK, I'll take a look. -- 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.1020110162911.1485E-100000>