From owner-freebsd-chat Thu Jul 15 11:35:24 1999 Delivered-To: freebsd-chat@freebsd.org Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (Postfix) with ESMTP id 65B3114D61 for ; Thu, 15 Jul 1999 11:35:18 -0700 (PDT) (envelope-from tlambert@usr07.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id LAA03792; Thu, 15 Jul 1999 11:49:30 -0700 (MST) Received: from usr07.primenet.com(206.165.6.207) via SMTP by smtp04.primenet.com, id smtpd003702; Thu Jul 15 11:49:16 1999 Received: (from tlambert@localhost) by usr07.primenet.com (8.8.5/8.8.5) id LAA28562; Thu, 15 Jul 1999 11:34:29 -0700 (MST) From: Terry Lambert Message-Id: <199907151834.LAA28562@usr07.primenet.com> Subject: Re: Known MMAP() race conditions ... ? To: unknown@riverstyx.net (Tani Hosokawa) Date: Thu, 15 Jul 1999 18:34:28 +0000 (GMT) Cc: tlambert@primenet.com, chat@FreeBSD.ORG In-Reply-To: from "Tani Hosokawa" at Jul 14, 99 07:37:50 pm 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 > On Thu, 15 Jul 1999, Terry Lambert wrote: > > > > Applications requiring large numbers of threads. > > Balk. "Rodents of unusual size? I don't believe they exist...". > > BTW, what would you consider to be a large number of threads? 64? 128? > More? How about a threaded webserver? Apache *is* going to be threaded, > you know... 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. That said, it's useful to be able to have a junior level person who doesn't understand finite state automata be able to produce code for the non-performance-critical parts of your project. At least they can contribute something, and they're cheaper than a senior level person who has a better engineering toolbox at their disposal (e.g. is more educated in the ways of code). Programs that require threads, particularly programs which require kernel threads, are, IMO, broken throw-away code. Topologically (I'm going to get beat on by another topologist for using physics instead of mathematics semantics for this one; please forgive me in advance, wherever you are... 8-)), there is no difference in kernel threads vs. user space call conversion threads vs. async I/O vs. finite state automata implemetnations of an algorithm, with the exception of SMP scalability -- and said scalability can be addressed very easily without resorting to kernel threads in all but the automata case. Given an OS that requires protection domain crossing (e.g. FreeBSD) in order to implement system services, kernel threading actually leads to significantly higher context switch overhead, unless one resorts to heroic (and arcane) avoidance mechanisms (I've discussed this before in this forum, probably ad-to-some-people's-nauseum 8-)). Threads are merely a convenience for linear thinkers, and kernel threads (in the presence of protection domain crossing requirements) are merely a convenience for junior implementors of operating systems. 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