From owner-freebsd-arch Sat Nov 20 21:24:56 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 0525D14DC8 for ; Sat, 20 Nov 1999 21:24:52 -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 GAA23385 for ; Sun, 21 Nov 1999 06:24:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12343 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:24:51 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 2AF7614DD3 for ; Sat, 20 Nov 1999 21:24:41 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt12.pcnet.net [206.105.29.86]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id AAA08704; Sun, 21 Nov 1999 00:22:16 -0500 (EST) Message-ID: <38378171.82BE24C3@vigrid.com> Date: Sun, 21 Nov 1999 00:21:53 -0500 From: "Daniel M. Eischen" X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 4.0-CURRENT i386) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: freebsd-arch@freebsd.org Subject: Re: Threads References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Julian Elischer wrote: > > On Sat, 20 Nov 1999, Daniel M. Eischen wrote: > > 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? I'd say that all upcalls are _not_ necessarily the result of a prior downcall. A subprocess that is preempted should force an upcall on the next available subprocess. I assume the UTS will install a set of upcall entry points to handle async notification events. We just need to define what events are passed between the UTS and the kernel. > 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. That's OK, but why not use a ucontext passed in with a new system call? Make the UTS supply ucontexts (made with makecontext) for event notifications also. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message