Date: Sun, 14 Nov 1999 07:50:00 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.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: <382EAFF8.7E144B94@vigrid.com> References: <Pine.BSF.4.10.9911132211250.21751-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > 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. I guess I don't see why we would _need_ new system calls. A process marks itself as wanting SAs and you put SA hooks in the sleep/wakeup functions. The SA hooks are conditional on the process being marked as wanting SAs. Old binaries using the old libc/libc_r wouldn't be marked as wanting SAs, so they'd continue to operate in the same way. I know I'm simplifying things a bit. Dan Eischen eischen@vigrid.com 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?382EAFF8.7E144B94>