[ On Sunday, January 4, 2004 at 22:40:42 (+0100), Manuel Bouyer wrote: ]
> Subject: Re: re-reading /etc/resolv.conf on change
>
> Well, talking with another developer offline about this, I figured that
> the problem isn't in the resolver per se, but in the gethostby* interface
> implementation.

True enough -- res_init() might not come immediately to mind if you're
just using gethostby*() for basic lookups.

This is in fact what seems to have confused the Mozilla developers to
the extent that they've proposed hacking directly on _res.options rather
than simply using res_[n]init() itself -- i.e. tying themselves even
more tightly to a particular set of gethostby*() implementations.

> Note that this interface use the resolver amongst other
> methods to retrieve the information (and may not even use the resolver
> at all, depending on configuration). Requiring applications to use res_init()
> to get up-to-date information from gethostby* is wrong because this mixes
> two different interfaces. 

I'm not so sure I'd say they're really two different interfaces.  The
gethostby*() API has a long a sordid history and as a result it brings
many differing sets of expectations to different "users".  Originally
they just read /etc/hosts.  Then along came the DNS to replace
/etc/hosts and so the same APIs were transplanted onto the DNS.  Sun and
maybe to a lesser degree in the past the likes of NCD and DEC have
adopted these interfaces to use their own "proprietary" naming services
in place of, or even in parallel with, the DNS (and with /etc/hosts
still being supported for backwards compatability).

However res_init() is indeed already called automatically on first
invocation of the gethostby*() APIs and so res_init() is "hidden" so
some extent by the latter and from that perspective you could say
they're at different levels.

I certainly have a great deal less objection to having gethostby*()
simply re-invoking res_init() internally if there's evidence available
that it needs to be called again than I do to having the resolver(3) do
this to itself.  Keeping a copy of the stat() structure and comparing
the st_mtime, st_dev, and st_ino values with current results every time
through just as nsdispatch() does seems like the right way to do this
and the best alternative would be to only redo the stat if at least 60
seconds had elapsed since the last time through.  Note there's no need
for using lstat() if you also compare the st_dev and st_ino values.

> Really ? So they are really confused by solaris I guess.

No doubt!  ;-)

> All applications want this. Or at last I want it in all applications.

I can understand why you want it, but I'm not so sure all applications
really want automatic config-file reloading, even if the config file in
question is one that's normally only used by "standard" library routines.

-- 
						Greg A. Woods

+1 416 218-0098                  VE3TCP            RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>