From owner-freebsd-chat Thu Jul 15 13:25:52 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp02.primenet.com (smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (Postfix) with ESMTP id 304DC14DDA for ; Thu, 15 Jul 1999 13:25:44 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id NAA17449; Thu, 15 Jul 1999 13:25:25 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp02.primenet.com, id smtpd017415; Thu Jul 15 13:25:18 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id NAA05487; Thu, 15 Jul 1999 13:25:16 -0700 (MST) From: Terry Lambert Message-Id: <199907152025.NAA05487@usr07.primenet.com> Subject: Re: Known MMAP() race conditions ... ? To: davids@webmaster.com (David Schwartz) Date: Thu, 15 Jul 1999 20:25:16 +0000 (GMT) Cc: tlambert@primenet.com, unknown@riverstyx.net, chat@FreeBSD.ORG In-Reply-To: <000f01becef1$b3d4cae0$021d85d1@youwant.to> from "David Schwartz" at Jul 15, 99 11:41:51 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > There is no "require" about it. Threads are a tool, and equivalent > > (and lower overhead) tools exist. > > > > The idea that threads are necessary at all is a psychological > > crutch. It has more to do with the inability of programmers > > to maintain state in a per connection structure, rather than > > on a stack. It's a programmer problem, in other words, based > > in procedural (rather than data flow) based ways of thinking. > > Okay, then, explain to me how you do 3,000 concurrent 'gethostbyname' calls > without writing your own resolver. By using the one that Paul Vixie wrote for 8.x. 8-). Or by downloading the Mozilla code, and implementing a DNS helper daemon via crib notes. > Explain to me how you make a webserver > that doesn't block if a disk write gets delayed without using one process > per request. aio_write, or on pre 4.1.3 SunOS, awrite. Alternately, the same way the "team" and "ddd" programs interleaved I/O. Or a daemon that does the I/O (we can call it "biod" 8-)). Or even by ensuring that sequential read-ahead in the buffer cache is triggered on an initial operation by overleading using "read(fd,buf, 0)". Or by using the little-used readv/writev calls, and queuing the I/O for completion to a daemon. Or using an async call gate. Or using processes with shared context. Or, if all other "configure" tests fail, implementing using kernel threads. > I will admit that there are always ways to avoid threads. Sure. There was > no task that was impossible before they existed. But paradigm bigotry is as > silly as operating system bigotry. I'm not bigoted against threads, per se, I am anti-overhead. This means context switch overhead, protection domain crossing overhead, stalling latency overhead (which isn't present in async I/O, but is in blocking read/write I/O), etc.. In general, overhead. You *could* implement threads which would be as light weight as possible (but still heavier weight than pure async I/O, but worth it for multiple CPU's in user space), but the only company that has come close to doing so is Sun. Unless you are writing your code specifically for Solaris 2.6 or higher, you would be best to avoid hard coding your assumptions about what concurrency facilities work best on each platform. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message