From owner-freebsd-arch Sat Nov 20 20:38:43 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 661CC15747 for ; Sat, 20 Nov 1999 20:38:36 -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 FAA23142 for ; Sun, 21 Nov 1999 05:38:36 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12219 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 05:38:35 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id BD50515747 for ; Sat, 20 Nov 1999 20:38:21 -0800 (PST) (envelope-from julian@whistle.com) Received: from current1.whiste.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id UAA36928; Sat, 20 Nov 1999 20:38:15 -0800 (PST) Date: Sat, 20 Nov 1999 20:38:15 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: freebsd-arch@freebsd.org Subject: Re: Threads In-Reply-To: <3837715C.A8222F4@vigrid.com> 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 Sat, 20 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer wrote: > > 7/ A method for treating a pagefault as a blocking IO and returning to the > > UTS when a thread get's a pagefault. > > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > > 8/ A method of delivering a signal to the UTS rathe than to any randomly > > running thread, and letting it decide which thread should handle it. > > (7 and 8 are related) > > How about an approach similar to Solaris? Deliver the signal to either a > special KSE/thread that acts as a proxy for the other threads? Or even > use an activation to notify the UTS of signals. From the UTS point of > view, notification through an activation might be simpler since we already > have to handle them (activations). We need to define EXACTLY what an activation means in our context. it's an upcall, but are all upcalls the result of a prior downcall, (or even a downcall that 'forked a new KSE')? how does an upcall know what to do whej it goes up? My suggested idea is that the UTS does a blocking syscall that notifies the kernel that it is now capable of receiving upcalls, and the kermnel duplicates that KSE and stack and returns on a new KSE. The UTS knows when it returns, to immediatly allocate a new stack and thread (probably already allocated and waiting before the downcall actually) and switches to the new stack (or maybe the downcall was already done on the new one in which case it restarts the old thread. In any case the thread that did teh downcall is teh nominated handler of async events. (?) > > Dan Eischen > eischen@vigrid.com > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message