Date: Sat, 13 Nov 1999 23:24:02 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: Michael Schuster - TSC SunOS Germany <michael.schuster@germany.sun.com>, "freebsd-arch@FreeBSD.ORG" <freebsd-arch@freebsd.org> Subject: Re: Threads goals and implementation Message-ID: <Pine.BSF.4.10.9911132211250.21751-100000@current1.whistle.com> In-Reply-To: <382DF821.EE3DE564@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9911132211250.21751-100000>