From owner-cvs-all Sat Mar 7 21:55:19 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07176 for cvs-all-outgoing; Sat, 7 Mar 1998 21:55:19 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from ns.mt.sri.com (sri-gw.MT.net [206.127.105.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07168 for ; Sat, 7 Mar 1998 21:55:14 -0800 (PST) (envelope-from nate@mt.sri.com) Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100]) by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id WAA17127; Sat, 7 Mar 1998 22:55:13 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id WAA06789; Sat, 7 Mar 1998 22:55:10 -0700 Date: Sat, 7 Mar 1998 22:55:10 -0700 Message-Id: <199803080555.WAA06789@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: John Birrell Cc: nate@mt.sri.com (Nate Williams), cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c In-Reply-To: <199803080549.QAA10989@cimlogic.com.au> References: <199803080536.WAA06540@mt.sri.com> <199803080549.QAA10989@cimlogic.com.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk [ Kernel thread being 'heavyweight' ] > > It seems to me we're checking off a box on someone's list of features > > w/out any regard to the usefulness of that feature. :( > > Yes, in the short term that's sort of true. Most of this is John Dyson's > work, so I'll ask him to correct me if I'm wrong. I believe it's a > case of learning to walk before learning to run. We all know about the > work that John has been doing to the VM. This includes support for > kernel threads. The simplest method of attack was to keep the kernel > threads like processes so that the VM side of things could be proven > to be stable. Then, with a stable VM, work could progress on pruning > kernel threads down so that things like signal handling would only > work at process level (like POSIX says), and not at individual thread > level. It'll require changes to the way things are scheduled and processes > forked. Fair enough, but it seems that a stable VM would be tested just as well with normal processes, so why the need for heavyweight 'threads'? > In the long term, kernel threads will be more than just a > check-in-a-box, IMHO. Good enough. After using threads consistently for about 18 months, I *like* them, but understand that if they become too heavy, most of the advantages of using them go away. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message