On Wed, 31 Dec 2003 16:06:57 +0100, Manuel Bouyer writes:
>> Is kqueue the right solution then?  How bad would it be to simply
>> open resolv.conf and fstat it?  You could record the mtime as well as 
>> the time you last looked and avoid doing so more than once in 
>> some window.  That would be bog simple and probably not too expensive.
>
>To achieve the same feature as kqueue (detect mv or rm), we need stat(),
>not fstat(). This means a NAMEI lookup for each call.

No, if you open the file - you are guaranteed that you have read what
it points to.  No need to worry about wether it is a symlink, or if
the link moved etc.  fstat is then ok - just to retrieve the mtime,
and other bits that could let to check if the file is the same as the
last one you parsed.

>I don't know if it's considered to be too expensive to do it for each
>resolver call (but I gess we could as well reread the resolv.conf file
>then :)

It would be too expensive for each call I think - but also
unnecessary. Once every N seconds would be plenty.  If you only do a
DNS lookup every few minutes then you'll do the check each call, but
for someone doing lookups many times a second you don't want that
overhead.

>I don't think doing the check once per time window is good enouth,
>because even if the window is small you may run in a DNS timeout, which is
>quite long. The changes have to be picked up immediatly.

Why?  How often do you change resolv.conf?  Even for laptop users we
are talking hours b/w changes - for most users more like months or
years.   In that timeframe an occasional DNS timeout is noise.

The kqueue solution described sounds way too complex for my liking.

>> You could also invalidate the handle on certain DNS failures to speed 
>> things up even with a bigger cycle time for re-checking...
>
>This would add yet more changes to the resolver :)

Not really.

>Also we need to have the change piked up immediatly, instead of
>waiting for a DNS timeout.

No - see above.

Thanks
--sjg