Date: Sun, 08 Mar 1998 13:55:19 +0800 From: Peter Wemm <peter@netplex.com.au> To: Nate Williams <nate@mt.sri.com> Cc: John Birrell <jb@cimlogic.com.au>, cvs-committers@FreeBSD.ORG Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c Message-ID: <199803080555.NAA02577@spinner.netplex.com.au> In-Reply-To: Your message of "Sat, 07 Mar 1998 22:36:31 MST." <199803080536.WAA06540@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <peter@netplex.com.au> Netplex Consulting To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803080555.NAA02577>