Date: Thu, 15 Jul 1999 20:25:16 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: davids@webmaster.com (David Schwartz) Cc: tlambert@primenet.com, unknown@riverstyx.net, chat@FreeBSD.ORG Subject: Re: Known MMAP() race conditions ... ? Message-ID: <199907152025.NAA05487@usr07.primenet.com> In-Reply-To: <000f01becef1$b3d4cae0$021d85d1@youwant.to> from "David Schwartz" at Jul 15, 99 11:41:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907152025.NAA05487>