Date: Fri, 26 Nov 1999 14:52:29 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: arch@freebsd.org Subject: Re: Threads stuff (fwd) Message-ID: <Pine.BSF.4.10.9911261451310.544-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
---------- Forwarded message ---------- Date: Fri, 26 Nov 1999 12:59:28 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Daniel M. Eischen <eischen@vigrid.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911261451310.544-100000>