Date: Sat, 20 Nov 1999 20:30:52 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "Daniel M. Eischen" <eischen@vigrid.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <Pine.BSF.4.10.9911202024070.6767-100000@current1.whistle.com> In-Reply-To: <3837715C.A8222F4@vigrid.com>
next in thread | previous in thread | raw e-mail | index | archive | help
y On Sat, 20 Nov 1999, Daniel M. Eischen wrote: > Julian Elischer 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, " (just one example of how they must be different) If it tuns out we think of somw really sneaky wayt of doing it so that they are compatible with old code, then we can always remove it, but I think I'd rather be absolutly certain that code calling a new version syscall knows what to do with the return values I return, and using a new syscall gate gives me that. > > > 6/ A manner of returnig to the UTS after the subprocess is rescheduled > > after a process preemption rather than returning to the thread that was > > pre-empted. > > 7/ A method for treating a pagefault as a blocking IO and returning to the > > UTS when a thread get's a pagefault. > > 7A/ A method of ensuring the UTS doesnt activate #7 if IT blocks. > > 8/ A method of delivering a signal to the UTS rathe than to any randomly > > running thread, and letting it decide which thread should handle it. > > (7 and 8 are related) > > How about an approach similar to Solaris? Deliver the signal to either a > special KSE/thread that acts as a proxy for the other threads? Or even > use an activation to notify the UTS of signals. From the UTS point of > view, notification through an activation might be simpler since we already > have to handle them (activations). > > 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?Pine.BSF.4.10.9911202024070.6767-100000>