From owner-freebsd-threads@FreeBSD.ORG Tue Jul 15 01:32:25 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC7F037B401 for ; Tue, 15 Jul 2003 01:32:25 -0700 (PDT) Received: from silver.he.iki.fi (silver.he.iki.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BB5243F75 for ; Tue, 15 Jul 2003 01:32:24 -0700 (PDT) (envelope-from pete@he.iki.fi) Received: from PETEX31 (h81.vuokselantie10.fi [193.64.42.129]) by silver.he.iki.fi (8.12.9/8.11.4) with SMTP id h6F8W9sL094129; Tue, 15 Jul 2003 11:32:09 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <049201c34aab$9361d070$812a40c1@PETEX31> From: "Petri Helenius" To: "Terry Lambert" , "Nate Williams" References: <007601c3467b$5f20e960$020aa8c0@aims.private> <004d01c348ae$583084f0$812a40c1@PETEX31> <3F12EF5A.71249E4D@mindspring.com> <16146.65087.69689.594109@emerger.yogotech.com> <3F13B1B4.8765B8F3@mindspring.com> Date: Tue, 15 Jul 2003 11:32:06 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 cc: Chris Knight cc: 'Kai Mosebach' cc: freebsd-threads@freebsd.org Subject: Re: LinuxThreads replacement X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2003 08:32:26 -0000 > > One evil purpose threads can be used for is to intentionally exploit > a decriptor close race with a blocking fd operation not protected by > giant, such that the close invalidates the descriptor before the > blocking operation completes, after which the code following the > blocking operation dereferences the (now invalid) descriptor contents. > Are you saying that this is a fundamental flaw in the design or a bug that hasnīt been fixed as of yet? > > I can also guarantee you from a performance perspective that an FSA > will beat almost anything else you could write, in terms of raw > ability to move data, or support high client loads, and will handily > beat threads, unless you are on an SMP system, and aren't willing to > run multiple copies of the program to do your scaling. > The usual thing I run across is to how effectively manage large fd_setīs without using threaded architechture. Spinning through a few thousand descriptors for almost each read gets expensive quickly. (or write, if youīre going that way) As usual, suggestions are welcome and might lead to more better code in the world... > Yes, this is somewhat mitigated by the fact that it's easier to write > threads code than an FSA, such that a lesser coder is still able to > be productive. As a class, it's a tool I would lump in with things > like "perl". > perl is good "Leatherman(TM)" tool. > All that said, FreeBSD's libkse is much less offensive, in terms of > overhead and cost, than a raw 1:1 implementation, like the one in > the current Solaris, or Linux. Solaris' argument is that it's hard > to get something like that correct, and they were worried about the > implementation bugs; that just adds fodder to the argument that you > should avoid threaded code, where possible. > There are people who solve their database performance problems by adding memory until everything is cached. Putting more hardware in seems to be default operating pattern for Solaris environments. And everybody seems to be happy with it. At least there the OS does not bloat constantly like it does in the WinTel land. Pete