From owner-freebsd-current Sat Sep 20 01:26:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA03930 for current-outgoing; Sat, 20 Sep 1997 01:26:48 -0700 (PDT) Received: from MindBender.serv.net (mindbender.serv.net [205.153.153.98]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA03905; Sat, 20 Sep 1997 01:26:41 -0700 (PDT) Received: from localhost.HeadCandy.com (localhost.HeadCandy.com [127.0.0.1]) by MindBender.serv.net (8.8.6/8.7.3) with SMTP id BAA22114; Sat, 20 Sep 1997 01:26:06 -0700 (PDT) Message-Id: <199709200826.BAA22114@MindBender.serv.net> X-Authentication-Warning: MindBender.serv.net: localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol To: Joe Eykholt cc: Nate Williams , Terry Lambert , toor@dyson.iquest.net, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) In-reply-to: Your message of Fri, 19 Sep 97 18:06:09 -0700. <34232181.718FFBF0@ipsilon.com> Date: Sat, 20 Sep 1997 01:26:06 -0700 From: "Michael L. VanLoon -- HeadCandy.com" Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >An aspect of sharing stacks that I didn't see mentioned is >that it's more efficient from an implementation viewpoint for >all threads to use the same virtual address space. >I don't think we should impose unnecessary requirements without >considering what would be lost in efficiency. > >If threads are to be truly light-weight, and you want the ability >to run threads from the same process on different processors, then >you'll want the two processors to use the identical virtual space >for that process. Otherwise the kernel will need to duplicate most of >the page directory in order to have some pages mapped differently >in different threads. ... that'll be almost as expensive as separate >processes. On a single processor, it'll mean doing a VM context >switch when switching between threads on the same processor. I agree to the point where we agree on the term for "virtual address space". When doing so, I am referring specifically to the heap and any memmory-mapped regions. I don't consider the stack to be part of that designation, at least for this specific case. This means that all threads in the process should share the same "virtual address space" for the lifetime of the process. Furthermore, their stacks should be functionally identical at the time the thread is created, and should be able to change separately, from that point forward. Similar to the case of how a child process state is set up right after a fork. This also means that any auto variables created on the stack by a functional call in one stack are local in scope and paradigm to that thread. They might actually be physically accessible from other threads in the process because of the physical implementation of the threading library, but that should be considered not-guaranteed, and a design no-no for this paradigm. I say "functionally identical" for the stacks because all threads that return from their initial start-time function should cleanly exit that thread context. In almost all cases that will not be the function "main()" except for the initial thread that started the process. My 3 or 4 cents... ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@MindBender.serv.net Contract software development for Windows NT, Windows 95 and Unix. Windows NT and Unix server development in C++ and C. --< Free your mind and your machine -- NetBSD free un*x >-- NetBSD working ports: 386+PC, Mac 68k, Amiga, Atari 68k, HP300, Sun3, Sun4/4c/4m, DEC MIPS, DEC Alpha, PC532, VAX, MVME68k, arm32... NetBSD ports in progress: PICA, others... -----------------------------------------------------------------------------