Date: Wed, 24 Nov 1999 14:03:02 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: "Daniel C. Sobral" <dcs@newsguy.com>, Julian Elischer <julian@whistle.com>, "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.SUN.3.91.991124134533.26314A-100000@pcnet1.pcnet.com> In-Reply-To: <199911241835.KAA19645@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Nov 1999, Matthew Dillon wrote: > I am getting confused by this whole KSE thing. All the threading I've > ever implemented has been done simply by splitting out the context > information from the Process into a Task, and then allowing N Tasks to > reference the same Process. There was no real distinction made between > kernel and user mode tasks or processes. In this context, what is a task? Something similar to a kernel thread? If there are N (user-level POSIX) threads in an application, how many tasks are there? > In such a scheme the switch code need only contain a single conditional: > One to check if the governing process for a task has a user-level mmu > directory that must be setup. That's it, done. > > I don't think separate scheduling queues are required either. I can see > absolutely no gain in performance by doing that and it unnecessarily > complicates the code. We can trivially use the existing priority > scheme to schedule interrupt tasks (threads). The kernel doesn't know at what priority the threads run, so how can it effectively schedule them? 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.SUN.3.91.991124134533.26314A-100000>