From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 16:07:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5E7816A4CE; Fri, 20 Feb 2004 16:07:32 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9302043D1F; Fri, 20 Feb 2004 16:07:32 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i1L07RSQ006249; Fri, 20 Feb 2004 19:07:27 -0500 (EST) Date: Fri, 20 Feb 2004 19:07:27 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Brian Fundakowski Feldman In-Reply-To: <200402202346.i1KNkbkI013945@green.homeunix.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@FreeBSD.org Subject: Re: Testers wanted: reentrant resolver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2004 00:07:33 -0000 On Fri, 20 Feb 2004, Brian Fundakowski Feldman wrote: > New and improved, my reentrant resolver patch even includes documentation! > What does it do, you ask? Why, it simply makes tabbed browsing in Mozilla > an order of magnitude faster! How does it do that, you ask? Well, it > simply makes h_errno and the getaddrinfo(3)/getipnodebyname(3) functions > thread-safe in a more intelligent way. There is still a global lock around > some pieces of data, but for the most part the global lock (which is what > serialized EVERY hostname lookup in threaded programs) is not contested. > It's still used for some NIS-related tasks, looking up hostents, and looking > up server port names, but that's not comparatively very important. The > resolver itself is a thread-safe backend where each thread gets its own > resolver that can run concurrently with the rest, so the time spent blocked > waiting for DNS responses is gone. > > Give it a try, and let me know how it works! > Ugh, can you put h_errno inside the per-thread res stuff. We shouldn't need to have to add special hooks in the threads libraries for this. -- Dan Eischen