From owner-freebsd-arch Tue Nov 23 21: 9:17 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id 7718815500 for ; Tue, 23 Nov 1999 21:09:14 -0800 (PST) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id GAA24419 for ; Wed, 24 Nov 1999 06:09:12 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA31785 for freebsd-arch@freebsd.org; Wed, 24 Nov 1999 06:09:10 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 62F4015500; Tue, 23 Nov 1999 21:08:41 -0800 (PST) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost [127.0.0.1]) by picnic.mat.net (8.9.3/8.9.3) with ESMTP id AAA85910; Wed, 24 Nov 1999 00:06:54 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Wed, 24 Nov 1999 00:06:54 -0500 (EST) From: Chuck Robey To: Daniel Eischen Cc: Julian Elischer , Nate Williams , freebsd-arch@freebsd.org, jasone@freebsd.org Subject: Re: Threads In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 23 Nov 1999, Daniel Eischen wrote: > > I'm wondering if there might possibly be some way to preserve some level > > of simplicity by keeping ksid'd like we keep pid's now, so that things > > that juggle a 32 bit entity keep on doing that, although perhaps under > > another name. > > I think you're basically right in keeping things simple. I think > that a non-MT process should be equivalent to a MT process. The > non-MT process has only one co-operating process (itself) and one > KSE. Whenever the non-MT process blocks in the kernel, there are > no more available KSEs, so another process is scheduled. OK, then let me ask another question: are we at all concerned about maybe following an already established thread API, or are we going to create our own? Things like user threads probably could work as then are now (albeit perhaps with only minor changes in performance) and stuff with runtimes like Java wouldn't care, but big programs like XFree86 and Netscape, and specially made daemons trying to do things like mass factoring, that are going to really want to manipulate real concurrency levels, they're going to have to be aware of our real underlying API, so making a unique one will complicate a lot of lives. > Dan Eischen > eischen@vigrid.com ---------------------------------------------------------------------------- Chuck Robey | Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770 | I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) ---------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message