From owner-cvs-all Sat Mar 7 21:56:52 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA07434 for cvs-all-outgoing; Sat, 7 Mar 1998 21:56:52 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA07364 for ; Sat, 7 Mar 1998 21:56:46 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from spinner.netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (8.8.8/8.8.8/Spinner) with ESMTP id NAA02577; Sun, 8 Mar 1998 13:55:20 +0800 (WST) (envelope-from peter@spinner.netplex.com.au) Message-Id: <199803080555.NAA02577@spinner.netplex.com.au> X-Mailer: exmh version 2.0.1 12/23/97 To: Nate Williams cc: John Birrell , cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c In-reply-to: Your message of "Sat, 07 Mar 1998 22:36:31 MST." <199803080536.WAA06540@mt.sri.com> Date: Sun, 08 Mar 1998 13:55:19 +0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Nate Williams wrote: > > > > that it will all just come out in the wash. Kernel threads aren't > > > > light weight, though. > > > > > > 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. > 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. libc_r/uthreads are implemented as a user-land select loop. It can't do blocking syscalls, and can't take advantage of multiple processors. 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. > 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. 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*.. > Nate Cheers, -Peter -- Peter Wemm Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message