Date: Sun, 28 Nov 1999 21:17:18 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: arch@freebsd.org Subject: Re: Threads stuff Message-ID: <Pine.BSF.4.10.9911282113490.544-100000@current1.whistle.com> In-Reply-To: <3841CFB4.F5B9A2BD@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 28 Nov 1999, Daniel M. Eischen wrote: > > > > bleah.. signals.. :-( > > If you are going to make signals compulsary then you might as well go the > > whole way and let the kernel keep the userland contexts as well. > > Which is Matt's suggestion. > > Like I said, I don't want signals; a scheduling upcall would be better. > For threads blocked in the kernel, I don't see much of a problem with > keeping the trapframe in the KSE since it's already on the kernel stack. > I don't want to keep contexts of threads not blocked in the kernel, though. a signal is just another upcall.. I'm using the terms interchangeably. > > > so, do the pictures help? > > Yes, I understood them just fine :) I'm still not sold on the new > syscall gate and IOCB, because I think we have to make at least one > system call when threads are switched or resumed. > I'm not completely sold on them either. I just have a gut feeling on it based on doing this for 25 years. > 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.9911282113490.544-100000>