Date: Sun, 21 Nov 1999 00:40:53 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Nate Williams <nate@mt.sri.com> Cc: Julian Elischer <julian@whistle.com>, freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <383785E5.C9193B77@vigrid.com> References: <3837715C.A8222F4@vigrid.com> <Pine.BSF.4.10.9911202024070.6767-100000@current1.whistle.com> <199911210514.WAA13707@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383785E5.C9193B77>