Date: Sat, 20 Sep 1997 01:26:06 -0700 From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@MindBender.serv.net> To: Joe Eykholt <jre@ipsilon.com> Cc: Nate Williams <nate@mt.sri.com>, Terry Lambert <tlambert@primenet.com>, toor@dyson.iquest.net, dyson@freebsd.org, karpen@ocean.campus.luth.se, current@freebsd.org Subject: Re: FYI: regarding our rfork(2) Message-ID: <199709200826.BAA22114@MindBender.serv.net> In-Reply-To: Your message of Fri, 19 Sep 97 18:06:09 -0700. <34232181.718FFBF0@ipsilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>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...
-----------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709200826.BAA22114>