From owner-freebsd-arch Tue Nov 30 10:42: 3 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 AB0D414D71 for ; Tue, 30 Nov 1999 10:42:01 -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 TAA09959 for ; Tue, 30 Nov 1999 19:42:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id TAA72016 for freebsd-arch@freebsd.org; Tue, 30 Nov 1999 19:41:59 +0100 (MET) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id F1AFC14D71 for ; Tue, 30 Nov 1999 10:41:53 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA26600; Tue, 30 Nov 1999 10:41:51 -0800 (PST) (envelope-from dillon) Date: Tue, 30 Nov 1999 10:41:51 -0800 (PST) From: Matthew Dillon Message-Id: <199911301841.KAA26600@apollo.backplane.com> To: "Daniel M. Eischen" Cc: Julian Elischer , arch@freebsd.org Subject: Re: Threads stuff References: <384270AE.D0250340@vigrid.com> <38440BAB.E547CA61@vigrid.com> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I think implementing a threading mechanism in the kernel is going to be a whole lot easier then implementing async call gates. In fact, the whole KSE mechanism is going to be easier to implement if they are integrated into a native kernel-based threading mechanism. If you *don't* do that, you *still* have to implement 80% of a kernel-based threading mechanism simply to be able to manage the KSE's, and so far I've heard half a dozen other special cases come up as being 'absolutely necessary' to prevent screwups. Frankly, when people talk about upcalls, wiring user memory, and controlling blocked kernel-mode KSEs from a user program... it *scares* me. I can implement kernel KSE's with an integrated kernel thread mechanism in a week, but I'm not going to do it unless I have a reasonable assurance that I can commit it :-). Most of the ground work has already been accomplished -- it became easy to do the moment the kernel stack was moved out of the common VM share. If we did things this way, I guarentee you that implementing a UTS will become trivial, without *any* special cases. In fact, it could be done without any upcalls either. A simple event reporting mechanism and a management thread to handle the everyone-is-asleep case is all you need. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message