From owner-freebsd-arch Sat Nov 20 20:13:57 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 16B0E14E48 for ; Sat, 20 Nov 1999 20:13:53 -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 FAA22962 for ; Sun, 21 Nov 1999 05:13:52 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id FAA12103 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 05:13:52 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 0D9E114E48 for ; Sat, 20 Nov 1999 20:13:39 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt25.pcnet.net [206.105.29.99]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id XAA01952; Sat, 20 Nov 1999 23:13:39 -0500 (EST) Message-ID: <3837715C.A8222F4@vigrid.com> Date: Sat, 20 Nov 1999 23:13:16 -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: > > 1/ KSE's (kernel schedulable Entities that are separate from processes). > 2/ SUB-processes. (each with ONE OR MORE KSEs) > 3/ Processes (each with one or more Sub processes) > 4/ A second call-gate to implement the syscalls that are changed > 5/ A different syscall protocol (using #4) to implement the fact that all > IO becomes Async in a thread setting, and to return control to the > (User level) Thread Scheduler (UTS) when a KSE blocks. I'd still like to know why we need another syscall gate in order to do this. From the sounds of it, you are envisioning having two implementations of every syscall, one for non-MT and one for MT. Or is it more because MT enabled system calls (internally) will need different arguments (struct proc p, struct thread t, whatever)? > 6/ A manner of returnig to the UTS after the subprocess is rescheduled > after a process preemption rather than returning to the thread that was > pre-empted. > 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). Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message