From owner-freebsd-hackers  Wed Sep 17 12:23:50 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA03846
          for hackers-outgoing; Wed, 17 Sep 1997 12:23:50 -0700 (PDT)
Received: from usr02.primenet.com (tlambert@usr02.primenet.com [206.165.6.202])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA03841
          for <freebsd-hackers@FreeBSD.ORG>; Wed, 17 Sep 1997 12:23:47 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr02.primenet.com (8.8.5/8.8.5) id MAA07899;
	Wed, 17 Sep 1997 12:23:09 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199709171923.MAA07899@usr02.primenet.com>
Subject: Re: What is wrong with this snipet?
To: Shimon@i-Connect.Net (Simon Shapiro)
Date: Wed, 17 Sep 1997 19:23:07 +0000 (GMT)
Cc: julian@whistle.com, thorpej@nas.nasa.gov, freebsd-hackers@FreeBSD.ORG
In-Reply-To: <XFMail.970916012056.Shimon@i-Connect.Net> from "Simon Shapiro" at Sep 16, 97 01:20:56 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> >  Obviously, multiple threads in the same process
> >  can see each other's stacks etc, and various 'threads' in a 
> >  process can 'migrate' to the other process if all shared
> >  processes can see all the stacks..
> 
> My apologies.  Again, I am not clear in my words.  I have no qualm, nor
> argument with the definition, not necessarily with the implementation.
> 
> From my naive point of view, what is less than very useful is the fact that
> one process exiting blows up the other which is not.  One would think that 
> since all processes now share the same address space, early exiters do not
> take the memory with them, but leave it for the others.

If you don't want shared address spaces, implement your programs as
processes instead of threads within a process.  A threaded process
necessarily implies a shared address space.

The need for the stack vidibility is, or should be, obvious, in the
same way that the use of thread local storage not allocated out of
the global heap should be obvious:

	thread1()
	{
		auto array[];
		...
		pass_array_ptr_to_thread2();
		interlock_completion_thread2();
		...
	}

	thread2()
	{
		for(;;) {
			wait_for_array_from_threadX();
			...
			signal_completion_thread2();
		}
	}

Say thread2() does something like async resolver lookups.


Now if you don't interlock, the auto goes away.  If the stacks are
not visible, the ptr reference to array[] goes away when thread1()
goes away.  Auto variables in a "thread_main" *are* thread local
storage: (1) they are scoped to the existance of the thread, and
(2) they go away [become untrustworthy] when the thread coes away
and they are made available for reallocation.


> >From my thinking (which is not necessarily correct), instead of new
> processes having to identify to themselves that they are new, and worry
> about securing pieces of their legitimate address space, the ones who leave
> the party do not take the lightbulbs, the food and the keg with them.
> 
> Being that I never drink and rarely ``party'', I may be wrong :-)

Threads, not processes.  As John says, they must call "thread_create()"
to instance themselves; the rfork(0 is an implementation detail which
you should not be considering as being responsible for thread creation.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.