Date: Thu, 17 Apr 2003 19:54:36 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Jacques A. Vidrine" <nectar@FreeBSD.org> Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: new NSS Message-ID: <3E9F68EC.D92FCF6E@mindspring.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
"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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9F68EC.D92FCF6E>