Date: Sat, 29 Jul 1995 17:10:07 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: terry@cs.weber.edu (Terry Lambert) Cc: bakul@netcom.com, freebsd-hackers@freebsd.org Subject: Re: pthreads Message-ID: <199507300010.RAA07970@ref.tfs.com> In-Reply-To: <9507292326.AA09991@cs.weber.edu> from "Terry Lambert" at Jul 29, 95 05:26:23 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Kirk McKusic and co. had a discussion on this topic when I didi the BSD4.4 course at UCB.. they were of the opinion that with recent changes to the efficiency of forking, the answer was to create the new 'rfork' call, where a forking process can decide what resources it wants to share with it's child.. options include: text space data space, stacks, file descriptor tables etc. using this approach, how do you tell two processes that are sharing all resources from threads? I have tucked away someone's 'rfork' implimentation for NetBSD.. I hope one day to take it out and examine it better.. DavidG had some comments on the topic too.. > > > > > While we're on the topic of threads, is there any work on getting > > > > kernel level threads into bsd? > > > > > I think that this is a natural consequence of allowing kernel reentrancy > > > in the SMP port... the kernel becomes internally preemption-safe. > > > > I think Marty Leisner is talking about multiple threads of > > control in a single address space. If so, this can be > > handled without kernel preemption. AFAIK kernel preemption > > is really only required to handle realtime processes. > > Well, he said "kernel level threads". Unless you buy into the SVR4 > definition, in which case a blocking operation will block the > scheduling unit instead of becoming an async operation and a thread > context switch. > > The SVR4 model has some serious drawbacks; if you do blocking calls > in all your threads, you must have N kernel threads for N user > threads. > > In general, there is little benefit to the SVR4 model other than > causing people to program in a more event driven way (which could > be argued) and a shared open file table and more complex signal > and exception handling requirements. The Dynix "sfork()" interface > provides the same functionality without adding silly restrictions > on stack preallocation and scheduling quantum competition. > > > > BTW, nice description of `priority inversion' w.r.t. > > prioritized realtime processes on MP systems (in your other > > message about Scheduling Algorithms). > > Why am I the only one who first found out about it from the IBM white > paper? Does everyone else on the planet call it "priority inversion" > instead of "priority lending"? > > 8-(. as in priority inherritance? > > > Terry Lambert > terry@cs.weber.edu > --- > Any opinions in this posting are my own and not those of my present > or previous employers. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507300010.RAA07970>