From owner-freebsd-arch Fri Nov 26 14:52:39 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 684121528C for ; Fri, 26 Nov 1999 14:52:36 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id XAA18424 for ; Fri, 26 Nov 1999 23:52:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id XAA47282 for freebsd-arch@freebsd.org; Fri, 26 Nov 1999 23:52:36 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 3CE8C1528C for ; Fri, 26 Nov 1999 14:52:30 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id OAA93274 for ; Fri, 26 Nov 1999 14:52:29 -0800 (PST) Date: Fri, 26 Nov 1999 14:52:29 -0800 (PST) From: Julian Elischer To: arch@freebsd.org Subject: Re: Threads stuff (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG ---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 12:59:28 -0800 (PST) From: Julian Elischer To: Daniel M. Eischen Subject: Re: Threads stuff Mind if I forward this to arch? we seem to have gone 'off the record' [dan says ok] (I just want to have everything 'on the record so people can catch up if needs be) On Fri, 26 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > > > Dan, I've been reading your context stuff. > > (in ~deischen/public_html on freefall) > > It's not up to date, but probably close enough to discuss. > > > I'm very confused about it.. > > I don't understand what it's for.. > > It's basically a setjmp/longjmp, but done from the kernel. > It could probably be done from libc like setjmp/longjmp, > but as long as you have to make a system call to set the > signal mask, it might as well be it's own system call. > Solaris and True64 UNIX both have getcontext(2) and > setcontext(2) system calls. > > http://www.opengroup.org/onlinepubs/7908799/xsh/getcontext.html > http://www.unix.digital.com/faqs/publications/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN2/INDEX.HTM > http://docs.sun.com:80/ab2/coll.40.5/REFMAN2/@Ab2TocView?Ab2Lang=C&Ab2Enc=iso-8859-1 > > I found the Solaris manpages for _lwp_makecontext(2) and > _lwp_create(2) interesting. > > One of my comments to Marcels signal changes was to use > a ucontext_t in signal handling so we would be able to > support {set|get|make|swap}context. > > > my reading of it is that it only sets and gets context from > > the process that is running, and since the process is > > running teh context in teh proc structure is of no interest.. > > Whether a running process is making a call to getcontext(2) or > a call to read(2), it's context can be retrieved in the same > way. So if a read(2) blocks, the kernel can switch to a new > context (similar to setcontext) that was provided at UTS > initialization. > > This was my original idea as to how the kernel could switch to > a new context when the process blocked. But this would involve > copying in and saving the current trapframe from the system > call that blocked, and copying out a new trapframe (destroying > the original trapframe). It seems like it would be much easier > to leave the current trapframe intact, and just change the > kernels pointer to a new trapframe that has already been set up. > What do you think? > > > Now I know that you wouldn't go to so much work for such a thing > > so I'm obviously misunderstand it.. > > Hmm, maybe I _am_ confused :-) > > > do you have any man-pages or docs as to how/why/where/when > > this is to be used? > > Yep, see above. I'll attach a test program that I used to verify > my implementation. > > Dan Eischen > eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message