Date: Sat, 29 Jul 95 19:19:38 -0700 From: Bakul Shah <bakul@netcom.com> To: terry@cs.weber.edu (Terry Lambert), Julian Elischer <julian@ref.tfs.com> Cc: freebsd-hackers@freebsd.org Subject: Re: pthreads Message-ID: <199507300219.TAA01038@netcom16.netcom.com> In-Reply-To: Your message of "Sat, 29 Jul 95 17:26:23 MDT." <9507292326.AA09991@cs.weber.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. My definition of user level threads: - multiple threads/address space - they must be preemptable - they must be allowed to make blocking system calls - on a MP system they may run concurrently on more than one processor I assumed (perhaps incorrectly) this is what Marty Leisner had in mind because without kernel level threads you can't do all of the above. However, preemption in kernel mode is not required. > 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"? Because `priority inversion', the problem, was described first. `priority lending', a solution to the problem, came later :-) Julian writes: > create the new > 'rfork' call, where a forking process can decide what resources it wants > to share with it's child.. I will note that Plan 9 has done this for a number of years. --bakul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507300219.TAA01038>