Date: Thu, 10 Jan 2002 11:20:56 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bruce Evans <bde@zeta.org.au> Cc: Peter Wemm <peter@wemm.org>, Nate Williams <nate@yogotech.com>, 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: <3C3DE998.44DCFA07@mindspring.com> References: <20020111000813.N12236-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > On Thu, 10 Jan 2002, Peter Wemm wrote: > > Nate Williams wrote: > > > Hmm, IIRC, Java's green threads saves the FP context everytime it does a > > > thread switch, since it has no way of knowing if the thread was doing FP > > > context. Is there a way to force get/setcontext to always/conditionally > > > save the FP context, for applications that either know they need to have > > > it saved? > > > > Exactly the problem. Userland cannot tell if it has touched FP or not > > except by touching it. This is where a system call is more efficient since > > to save FP context you are doing trap recovery on top of doing the work. > > Actually, userland can look at the state bit in %msw (on i386's) to > tell if it can look at the state without trapping. However, this is > not very useful. The state will often be in the kernel, and then > userland will have to trap to the kernel too look at it. The trap > may as well be a syscall that fetches all the state. How onerous would it be to look at the register in the kernel before returning to user space, following a context switch? I really don't think the lazy task switching FPU state saving needs to care about threads, only about processes... and once the bit is set, it's set, right? -- 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?3C3DE998.44DCFA07>