From owner-freebsd-current@FreeBSD.ORG Thu Apr 17 19:56:03 2003 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 478C737B401; Thu, 17 Apr 2003 19:56:02 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2744F43FBF; Thu, 17 Apr 2003 19:56:02 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0309.cvx40-bradley.dialup.earthlink.net ([216.244.43.54] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 196M2g-0001jY-00; Thu, 17 Apr 2003 19:55:59 -0700 Message-ID: <3E9F68EC.D92FCF6E@mindspring.com> Date: Thu, 17 Apr 2003 19:54:36 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" References: <20030417141133.GA4155@madman.celabo.org> <1050590195.76150.8.camel@owen1492.uf.corelab.com> <20030418002346.A91615@iclub.nsu.ru> <20030417173607.GA2682@madman.celabo.org> <20030418010935.GD4001@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a45a7b153d160b09662de726ac918a60b8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c cc: Garrett Wollman cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: new NSS 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: Fri, 18 Apr 2003 02:56:03 -0000 "Jacques A. Vidrine" wrote: > On Thu, Apr 17, 2003 at 04:44:05PM -0400, Garrett Wollman wrote: > > One possible way around this is to add an external resolver (like > > Solaris's `nscd'); the static library can use a stub routine to call > > the resolver if possible (i.e., the machine is running multiuser), and > > then fall back to the built-in databases if this fails. This way, > > only the users who needed loadable NSS modules would pay the cost. > > Indeed, even in a completely dynamically-linked system, an nscd has > some value. When we do get one, it would likely be optional, however. > Some NSS modules already do their own caching; and also sometimes the > complexity is not needed. In any case, the internal libc interfaces > must stablize before we can move forward. It would be nice to have > something for FreeBSD 5.2. For threads reentrancy, an external resolver makes a *lot* of sense. Right now, people have been suggesting reentrant resolver code in libc, which is fine, until you have 10,000 threads in a network protocol server (e.g. HTTP), all of which need to do reverse lookups for logging purposes. Minimally, a reentrant resolver library would have to have a limited number of actual sockets on which pending UDP requests are outstanding, since it's not really possible to match an answer with a specific request, in most cases. An nscd solves the problem nicely. In addition, since the local connection can be TCP rather than UDP, and handle the multiplexing of the request by thread ID (or whatever ID you choose to use as a request/response prefix), you can have a single socket used in the threaded program, not one per outstanding request, or some limited number with a turnstile protecting them (e.g. what Microsoft calls "apartment model"). All in all, this is a much better idea, overall, than making the standard libc versions thread reentrant. The model in the the nscd itself, if it uses threads at all, would probably have to be "apartment", anyway, to bound the amount of resources used (same reason the thing should cache when it can, in all cases, even if not requested to cache, and even if there is a cache in the program talking to it). -- Terry