Date: Sat, 20 Nov 1999 23:13:16 -0500 From: "Daniel M. Eischen" <eischen@vigrid.com> To: Julian Elischer <julian@whistle.com> Cc: freebsd-arch@freebsd.org Subject: Re: Threads Message-ID: <3837715C.A8222F4@vigrid.com> References: <Pine.BSF.4.10.9911201809100.6767-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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)? > 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?3837715C.A8222F4>