From owner-cvs-lib Sat Mar 7 22:22:41 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA11016 for cvs-lib-outgoing; Sat, 7 Mar 1998 22:22:41 -0800 (PST) (envelope-from owner-cvs-lib) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA11003; Sat, 7 Mar 1998 22:22:25 -0800 (PST) (envelope-from toor@dyson.iquest.net) Received: (from root@localhost) by dyson.iquest.net (8.8.8/8.8.8) id BAA02010; Sun, 8 Mar 1998 01:21:47 -0500 (EST) (envelope-from toor) Message-Id: <199803080621.BAA02010@dyson.iquest.net> Subject: Re: cvs commit: src/lib/libc_r/uthread pthread_private.h uthread_yield.c In-Reply-To: <199803080535.VAA08550@dingo.cdrom.com> from Mike Smith at "Mar 7, 98 09:35:03 pm" To: mike@smith.net.au (Mike Smith) Date: Sun, 8 Mar 1998 01:21:47 -0500 (EST) Cc: jb@cimlogic.com.au, nate@mt.sri.com, mike@smith.net.au, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, cvs-lib@FreeBSD.ORG From: "John S. Dyson" Reply-To: dyson@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-lib@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Smith said: > > So what differentiates these "heavyweight" threads from "lightweight" > threads? > There is redundant information in each thread, and we need to push the machine state into each thread. Things like pwd, etc need to adhere to POSIX as to where the various process state items are. For now, we are keeping the info in each process (thread). As far as VM state goes, that will be fully shared and locked. We'll get a large part of the advantage of the shared VM space, etc. But we won't get everything, and we will likely have a more complete implementation in the 3.1 timeframe. One purpose for getting the kernel threads in for 3.0 is so that we can run packages that depend on threads without gross or strange hacks. For example, if Netscape depended upon a kernel threads implementation, who cares at all if our implementation is a little slower? The key is that the software will work, and the performance will do nothing but get better. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig.