Date: Sat, 20 Nov 1999 22:14:33 -0700 From: Nate Williams <nate@mt.sri.com> To: Julian Elischer <julian@whistle.com> Cc: "Daniel M. Eischen" <eischen@vigrid.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <199911210514.WAA13707@mt.sri.com> In-Reply-To: <Pine.BSF.4.10.9911202024070.6767-100000@current1.whistle.com> References: <3837715C.A8222F4@vigrid.com> <Pine.BSF.4.10.9911202024070.6767-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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, " Not only that, but you need a way for it to be 'aborted' out and have it cleanup as it goes. I suspect that this will require re-writing a large number of syscalls with threading in mind, and leaving the 'old' calls in place will allow more flexibility as things change. I could envision the 'old' calls going away at some point as the new calls get completely fleshed out and tested, to be replaced with simple wrappers for the threaded calls. Nate 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?199911210514.WAA13707>