On 716095926 seconds since the Beginning of the UNIX epoch
Matthias Buelow wrote:
>

>Say you're doing an "ls -l" on your typical pop3-mailspool, with a 1000
>users.  This already takes 10-20secs if using NIS (over 100mbit),
>and that's using library functions that communicate via IPC with the
>server.
>Starting a seperate program for uid/gid resolution each time would be
>prohibitively expensive.

An authentication daemon wouldn't start a separate process for each
uid/gid resolution, it would be a persistent daemon that stayed
around between different sessions.  Also, since the protocol has
not been designed yet, it would certainly be possible to come up
with something that batched requests in a consistent way for
situations such as these to minimise the syscall/ctx switch overhead.
In fact, the getpwent(3) and getgrent(3) functions could just do
a little caching and the like to enhance the performance of third
party apps and we could extend the API for our own programs to have
a moral equivalent of get{pw,gr}{nam,uid}v() which would take a
vector of inputs and return a ve3ctor of outputs.  This would allow
all of the requests to be performed very quickly for ls(1) et al.

In fact it looks like there are already library functions to help
with the caching, pwchache(3).  And, from a quick perusal it looks
like ls(1) already uses it.

 == Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/  ==
 == The Unofficial NetBSD Web Pages        http://www.Imrryr.ORG/NetBSD/  ==
 == The NetBSD Project                            http://www.NetBSD.ORG/  ==
 == Ponte, Inc.                                    http://www.ponte.com/  ==