From owner-freebsd-arch Wed Nov 24 11: 6:20 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 3476714DF2 for ; Wed, 24 Nov 1999 11:06:17 -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 UAA08701 for ; Wed, 24 Nov 1999 20:06:15 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA35201 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 20:06:15 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id E67BA150F3 for ; Wed, 24 Nov 1999 11:06:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA20045; Wed, 24 Nov 1999 11:05:54 -0800 (PST) (envelope-from dillon) Date: Wed, 24 Nov 1999 11:05:54 -0800 (PST) From: Matthew Dillon Message-Id: <199911241905.LAA20045@apollo.backplane.com> To: Daniel Eischen Cc: Matthew Dillon , "Daniel C. Sobral" , Julian Elischer , "Daniel M. Eischen" , freebsd-arch@freebsd.org Subject: Re: Threads References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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? N. A task is simply an execution context for the scheduler. That's it, nothing special. The scheduler need only know about tasks and doesn't really have to know about meta-data such as (except for the MMU context) data stored in Processes, nor does it really need to know what *kind* of task it is messing with. Simplicity is the best solution. :> 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 If you have one Task == one Thread, the priority is in the Task structure, so the kernel would know. Obviously the scheduler must know or it can't properly schedule the execution context. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message