Date: Sat, 20 Nov 1999 18:50:24 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: freebsd-arch@freebsd.org Subject: Thread summary.. needs? Message-ID: <Pine.BSF.4.10.9911201834440.6767-100000@current1.whistle.com>
next in thread | raw e-mail | index | archive | help
I just summarised elsewhere so I'm repeating here.. On Sat, 20 Nov 1999, Matthew Jacob wrote: > > Actually, to be fair about this, Julian *did* announce to all and sundry > that there would be a discussion about threads. I lurked and followed it > from a distance throughout the week or so it was active. Since it didn't > really touch that much on kernel threads, I didn't have a great amount of > interest in leaping in (the last time I did user level thread work was in > helping Nawaf polish off/disagree with some Posix stuff multi years ago > wrt signal handling). > > It did seem that the discussion was productive, but since it wasn't really > my table, I didn't get involved. Now, if there's some talk about kernel > threads, or more precisely, how a fully threaded kernel will need changes > to the device I/O model, then I'm more interested. That's peculiar because teh first week was just discussing the goals. from there we got to the fact that we need the following kernel support. 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. 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) The discussion has basically stopped the last 6 days as everyone has been busy but I was getting ready to post some stuff tonight. -------------------- more added--------------- Basically I see some basic work being needed so we can start this.. 1/ separation of struct proc into (at least) 2 parts. one ofr the KSE and one for the proc. thoud there be a separation between the prc and hte sub-proc? remember the subproc is the guy that has the priorities and KSE's are scheduled according to which sub-proc they are attached to. (I'm starting to to wonder if we don't need 3 separate structs, thogh maybe all subprocs are also procs). 2/ we need to allocate ourselves a new call gate so that we can start experimenting with the syscall protocol we will need to implement. 3/ A KSE allocator that caches KSEs to speed up allocation would be good. This should fit togehter with whatever the people are doing on real 'kernel internal threads' and SMP. julian 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.9911201834440.6767-100000>