From owner-freebsd-arch Sun Oct 31 18:57: 4 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 2DB0C14DF5 for ; Sun, 31 Oct 1999 18:57:01 -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 DAA01601 for ; Mon, 1 Nov 1999 03:57:00 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id DAA69597 for freebsd-arch@freebsd.org; Mon, 1 Nov 1999 03:57:00 +0100 (MET) Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 98F3414DF5 for ; Sun, 31 Oct 1999 18:56:54 -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 VAA04365; Sun, 31 Oct 1999 21:55:59 -0500 (EST) (envelope-from chuckr@picnic.mat.net) Date: Sun, 31 Oct 1999 21:55:59 -0500 (EST) From: Chuck Robey To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads goals version II 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 Sun, 31 Oct 1999, Julian Elischer wrote: > 7/ Some well documeted scheme exists for handling signals and other async > events. Would this possibly mean that if a signal isn't caught, it's action reflects upon the entire process, but if it's caught, a thread-specific handler catches it? That would mean that the kernel is going to have to be able to identify, when a signal comes in, both a process ID and (because a signal may post against other than the active process, such as a timer signal) a thread ID. Or would an uncaught signal merely act on the active thread? > 10/ Quick access to curthread and thread specific data. We shouldn't > have to enter the kernel to get this. This should also be true > for threads spread across multiple [lightweight] processes. This is the my question (the other was an outgrowth), I guess, which is, would /proc be modified, and then would ps report both on processes *and* threads (maybe sorted, the make more sense)? > 11/ Ability for the threads library to cancel/terminate a thread > blocked in the kernel. > > 12/ Processorr affinity for threads. It seems to me that it would be pretty likely that a thread would want to bias this choice itself. This is pretty closely identified with items 13 and 13A, isn't it? I would be pretty surprised if significantly better programs couldn't be written if a program could set it's own bias here. If each thread could be given it's own small block of kernel data, then I think that the rest could be done, right? Are we trying to find a way to do this with minimal kernel resources, is that it? ---------------------------------------------------------------------------- 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