From owner-freebsd-arch Sat Nov 13 23:25: 3 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 1314114C83 for ; Sat, 13 Nov 1999 23:24:59 -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 IAA15559 for ; Sun, 14 Nov 1999 08:24:54 +0100 (CET) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id IAA38789 for freebsd-arch@freebsd.org; Sun, 14 Nov 1999 08:24:54 +0100 (MET) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id D95EB15206 for ; Sat, 13 Nov 1999 23:24:36 -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 XAA57038; Sat, 13 Nov 1999 23:24:04 -0800 (PST) Date: Sat, 13 Nov 1999 23:24:02 -0800 (PST) From: Julian Elischer To: "Daniel M. Eischen" Cc: Michael Schuster - TSC SunOS Germany , "freebsd-arch@FreeBSD.ORG" Subject: Re: Threads goals and implementation In-Reply-To: <382DF821.EE3DE564@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, 13 Nov 1999, Daniel M. Eischen wrote: > > It is probable that we will need a different syscall calling convension > > to handle teh async nature of the world. If we use a second syscall gate, > > we can intermix old and new system calls during development. > > OK, I can see how a different syscall gate might be useful during > development. more than that.. Old binaries must continue to run, and thus programs linked with libc might continue to use the old syscalls (probably less overhead) while prrograms using libc_r will call the new call-gate with a protocol mor esuited to the new ideas. > > Currently, if I read the source correctly, a procs p_paddr (struct user) > includes the kernel register save area and the kernel stack, and is > swappable. If we start allowing more kernel contexts (KSEs), do we > also want to allow them to be swappable? > possibly. > > The struct procs describe "SUBPROCESSES" and are in turned grouped in some > > way to form a 'PROCESS' > > > > The more interesting question is "What do we do when we > > cannot allocate any more of these? (KSEs)" (either through limits or > > resource shortage). > > Tell the UTS when the limit has been reached, then block without SA > notification when the limit has been exceeded? > It may be reached when some OTHER process uses the last one... so you may not be able to notify.. I guess just blocking is the answer. Julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message