From owner-freebsd-current  Sat Sep 20 01:07:04 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA29814
          for current-outgoing; Sat, 20 Sep 1997 01:07:04 -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 BAA29773;
          Sat, 20 Sep 1997 01:06:45 -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 BAA21983; Sat, 20 Sep 1997 01:06:08 -0700 (PDT)
Message-Id: <199709200806.BAA21983@MindBender.serv.net>
X-Authentication-Warning: MindBender.serv.net: localhost.HeadCandy.com [127.0.0.1] didn't use HELO protocol
To: Terry Lambert <tlambert@primenet.com>
cc: toor@dyson.iquest.net (John S. Dyson), nate@mt.sri.com, 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 20:27:45 -0000.
             <199709192027.NAA01303@usr03.primenet.com> 
Date: Sat, 20 Sep 1997 01:06:02 -0700
From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@MindBender.serv.net>
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


I've been following all this with slight interest, but thought I
should contribute in this case...

>> > 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:

I believe this is Just Plain Wrong.  Auto variables inside a function
call are local to that specific instance of that function.  Since a
specific instance of a function is instantiated on a specific thread
of execution, that means the local auto-variables have a scope local
to that specific thread, as well.  To assume there is a need to
consider otherwise is to needlessly complicate a clean paradigm.

If state needs to be kept among multiple threads, it should be done so
globally (or better, in a "global" namespace or class specificly for
this purpose).

>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.

This would be better accomplished with global metephores, critical
sections, and/or mutexes.  Or, as stated above, metephores, critical
sections, and/or mutexes stored in a global namespace or class
specifically for this purpose.

Of course, this assumes that such primitives are even available, which
they are not in standard libc.  But neither are threads, indicating
additional libraries are already in use.

-----------------------------------------------------------------------------
  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...
-----------------------------------------------------------------------------