From owner-cvs-all Sat Mar 7 21:50:34 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA06102 for cvs-all-outgoing; Sat, 7 Mar 1998 21:50:34 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA06011 for ; Sat, 7 Mar 1998 21:50:22 -0800 (PST) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.5/8.8.7) id QAA10989; Sun, 8 Mar 1998 16:49:48 +1100 (EST) (envelope-from jb) From: John Birrell Message-Id: <199803080549.QAA10989@cimlogic.com.au> Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c In-Reply-To: <199803080536.WAA06540@mt.sri.com> from Nate Williams at "Mar 7, 98 10:36:31 pm" To: nate@mt.sri.com (Nate Williams) Date: Sun, 8 Mar 1998 16:49:47 +1100 (EST) Cc: jb@cimlogic.com.au, nate@mt.sri.com, cvs-committers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Nate Williams wrote: > You can do that easily enough know with mmap'd files, and or SYSV shmem. > It would seem to me that heavy-weight threads don't buy you anything > that you can't already do know. Heck, someone could write up a library > that does that already, making the details hidden like the user-land > pthreads library. > > 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. In the long term, kernel threads will be more than just a check-in-a-box, IMHO. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message