Re: HEADS UP: new NSS

"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