From owner-freebsd-current  Fri Sep 19 13:28:08 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id NAA05915
          for current-outgoing; Fri, 19 Sep 1997 13:28:08 -0700 (PDT)
Received: from usr03.primenet.com (tlambert@usr03.primenet.com [206.165.6.203])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id NAA05896;
          Fri, 19 Sep 1997 13:27:58 -0700 (PDT)
Received: (from tlambert@localhost)
	by usr03.primenet.com (8.8.5/8.8.5) id NAA01303;
	Fri, 19 Sep 1997 13:27:46 -0700 (MST)
From: Terry Lambert <tlambert@primenet.com>
Message-Id: <199709192027.NAA01303@usr03.primenet.com>
Subject: Re: FYI: regarding our rfork(2)
To: toor@dyson.iquest.net (John S. Dyson)
Date: Fri, 19 Sep 1997 20:27:45 +0000 (GMT)
Cc: nate@mt.sri.com, dyson@FreeBSD.ORG, karpen@ocean.campus.luth.se,
        current@FreeBSD.ORG
In-Reply-To: <199709191848.NAA02645@dyson.iquest.net> from "John S. Dyson" at Sep 19, 97 01:48:22 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > The great strength about Unix is that another 'process' can'tt muck with
> > another 'processes' easily, and with threads I'd like to see this taken
> > to whatever extreme as possible given the constraints of implementation.
>
> The threads are a different issue.  I don't disagree with the threads
> stacks being isolated for philosophical reasons -- however it is just
> wrong from a compatibility standpoint.

Exactly so.  If you want this protection, implement using processes
instead of threads.

The problem is that I may pass auto variables between threads:

	/* one of many threads with work to be done*/
	thread1()
	{
		struct req my_request;

		my_request.x = ...;
		my_request.y = ...;

		do_requeust( &my_request);

		...
	}

	/* block calling thread until request completed*/
	do_request( struct req *preq)
	{
		...
		enqueue( preq);
		...
		while( preq->status != REQ_COMPLETE)
			YIELD;
	}


	/* lives only to service requests*/
	thread2()
	{
		struct req *preq;

		for(;;) {
			/* spin to get next work item*/
			while( ( preq = dequeue()) == NULL)
				YIELD;

			/* service work item*/
			...

			/* mark work item completed*/
			preq->status = REQ_COMPLETE;
		}
	}

I might do this, for example, if my work items were DNS lookups, etc.,
which had to be accomplished serially, or with some maximum concurrency
(say I start no more than 3 thread2's, and 10's of thread1's) because
of load characteristics.

In any case, if thread2 did not have access to thread1's stack, the
first time it tried to dereference preq, one of two things would
happen:

	1)	It would segfault because the page wasn't mapped
		for thread2

	2)	It would dereference data from thread2's stack or
		thread local storage instead of thread1's stack,
		because that's the only way a page would be mapped
		there in thread2's address space.

Either of these is bad.

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