From owner-freebsd-hackers Sat Jul 29 17:10:28 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.11/8.6.6) id RAA07054 for hackers-outgoing; Sat, 29 Jul 1995 17:10:28 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.11/8.6.6) with ESMTP id RAA07046 for ; Sat, 29 Jul 1995 17:10:27 -0700 Received: (from julian@localhost) by ref.tfs.com (8.6.11/8.6.9) id RAA07970; Sat, 29 Jul 1995 17:10:07 -0700 From: Julian Elischer Message-Id: <199507300010.RAA07970@ref.tfs.com> Subject: Re: pthreads To: terry@cs.weber.edu (Terry Lambert) Date: Sat, 29 Jul 1995 17:10:07 -0700 (PDT) Cc: bakul@netcom.com, freebsd-hackers@freebsd.org In-Reply-To: <9507292326.AA09991@cs.weber.edu> from "Terry Lambert" at Jul 29, 95 05:26:23 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2488 Sender: hackers-owner@freebsd.org Precedence: bulk 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. >