From owner-cvs-all Sat Mar 7 22:04:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA08947 for cvs-all-outgoing; Sat, 7 Mar 1998 22:04:32 -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 WAA08937 for ; Sat, 7 Mar 1998 22:04:29 -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 XAA17191; Sat, 7 Mar 1998 23:03:54 -0700 (MST) (envelope-from nate@rocky.mt.sri.com) Received: by mt.sri.com (SMI-8.6/SMI-SVR4) id XAA06928; Sat, 7 Mar 1998 23:03:44 -0700 Date: Sat, 7 Mar 1998 23:03:44 -0700 Message-Id: <199803080603.XAA06928@mt.sri.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Peter Wemm Cc: Nate Williams , John Birrell , cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c In-Reply-To: <199803080555.NAA02577@spinner.netplex.com.au> References: <199803080536.WAA06540@mt.sri.com> <199803080555.NAA02577@spinner.netplex.com.au> X-Mailer: VM 6.29 under 19.15 XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > > > If kernel threads aren't light-weight, then what differentiates them > > > > from processes? > > > > > > Shared address space. > > > > You can do that easily enough know with mmap'd files, and or SYSV > > shmem. ... > libc_r/uthreads are implemented as a user-land select loop. I'm aware of that. > It can't do > blocking syscalls, and can't take advantage of multiple processors. I'm also aware of that as well. > That's what these changes are about. In spite of the fact that they > are seperate processes, having the shared address space means we can > (greatly) streamline context switching between them. So, they are more like slightly-lighter weight prorcesses? > > 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. :( > > I tend to think of threads being able to take advantage of multiple cpu's > as pretty useful. We can do that with processes now. As I stated originally, what advantages do these 'heavy-threads' have over standard processes. So far the answer is context switches are faster due to shared address space. Other than that it appears that they are still pretty 'heavy'. > Yes, we can probably go further and have lightweight threads (hundreds? > thousands?) within a process, but that requires more extensive changes, > especially with the implications of scheduling the same containing process > multiple times on different cpu's.... *shudder*.. I understand. I want the brass ring now, not later. :) :) :) I as well as many others couldwrite applications *right now* that could take advantage of truly lightweight kernel threads for socket communication. It would be nice to have hundreds if not thousands of them running around that take up *significantly* less resources than associated processes. (resources include context switches, but also include things like memory usage, etc....) Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message