From owner-freebsd-arch Sat Nov 20 21:41:35 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 1884F14E5A for ; Sat, 20 Nov 1999 21:41:32 -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 GAA23510 for ; Sun, 21 Nov 1999 06:41:27 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id GAA12475 for freebsd-arch@freebsd.org; Sun, 21 Nov 1999 06:41:26 +0100 (MET) Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id 3A4FC14E5A for ; Sat, 20 Nov 1999 21:41:17 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from vigrid.com (pm3-pt44.pcnet.net [206.105.29.118]) by pcnet1.pcnet.com (8.8.7/PCNet) with ESMTP id AAA10388; Sun, 21 Nov 1999 00:41:16 -0500 (EST) Message-ID: <383785E5.C9193B77@vigrid.com> Date: Sun, 21 Nov 1999 00:40: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: Nate Williams Cc: Julian Elischer , freebsd-arch@freebsd.org Subject: Re: Threads References: <3837715C.A8222F4@vigrid.com> <199911210514.WAA13707@mt.sri.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Nate Williams 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)? > > > > THe return value system for MT syscalls is by necessity differnt from non > > MT ones, and we need to continue to support old binaries. > > therefore by deduction, either a new syscall gate, or each syscall needs > > to be somehow aware as to how it was called. teh new call gate is the > > simplest way, and even allows intermixing of the new and old calls. > > > > New calls must be able to return and say > > "hey it's not me returnuing, but actually a new KSE, " Now I think I understand what Julian is talking about. Suppose a read(2) blocks in an MT application. Julian is thinking that read(2) returns with -1 and errno set to EMTBLOCKED or something like that? I don't think a blocking system call should return at all. Control should be returned to the UTS at another entry point and on another stack. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message