Date: Tue, 5 Feb 2002 17:53:01 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: Matthew Dillon <dillon@apollo.backplane.com>, Dan Eischen <eischen@vigrid.com>, bde@FreeBSD.ORG, peter@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: getsetcontext system call Message-ID: <Pine.GSO.4.10.10202051741300.179-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0202051433380.87080-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 Feb 2002, Julian Elischer wrote: > On Tue, 5 Feb 2002, Daniel Eischen wrote: > > > On Tue, 5 Feb 2002, Julian Elischer wrote: > > > On Tue, 5 Feb 2002, Daniel Eischen wrote: > > > > > > > On Tue, 5 Feb 2002, Matthew Dillon wrote: > > > > > I thought we were trying to avoid having to make any system calls on > > > > > a userland thread context switch. > > > > > > > > In the threads library, we'll use our own library routines to > > > > do this (hopefully) without having to make a system call. > > > > > > Or maybe use kernel entries that are already hapenning anyway..... > > > > Huh? > > I was thinking that when saving thread context back to userland > after completing a syscall but before going on to another > syscall, we can save lots of FP state etc as well. Yeah, I was assuming that under a KSE enabled process, the state of blocked threads gets saved out to userland in mcontext_t format (which would include the FPU state, if used). But the threads library can also force a context switch without having it blocked in the kernel, so the threads library needs the equivalent of a getcontext() as well as setcontext(). -- 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.GSO.4.10.10202051741300.179-100000>