Date: Sat, 20 Sep 1997 01:06:02 -0700 From: "Michael L. VanLoon -- HeadCandy.com" <michaelv@MindBender.serv.net> 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) Message-ID: <199709200806.BAA21983@MindBender.serv.net> In-Reply-To: Your message of Fri, 19 Sep 97 20:27:45 -0000. <199709192027.NAA01303@usr03.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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... -----------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709200806.BAA21983>