The thing is that (I just read about policy vs mechanism in a playboy, 
so let me put it in:)

[policy]
the 1st question is:
	should resolv.conf be reloaded automatically if it is
	modified?

My understanding is that it should be automatically reloaded. An 
application queries the resolver to get an answer, it won't say "take a 
margarita and then tell me the IP of foo, the guy who lives at 
sosalitos", it'll only says "what's the IP of foo?" At least, this is 
the way the resolver has always been _used_ [vs documented].

Also, the problem isn't just for host to IP or IP to host, it's also a 
problem for getting the MX, and the like (so modifying gethostbystuff 
doesn't solve the issue, if we happen to agree there's an issue).

Of course, this will cause trouble to those who relied on the 
"misfeature" to use differnt resolv.conf for differnt apps. But
  hey have been clever enough to do that, so they can be clever enough 
to get around any modifications.

[mechanism]
If so, the questions are:
	1- how to detect the modification
	2- where to implement the change

1- There are multiple possiblities:
	* notification (via a signal or whatever)
	However, there is no need for notification, since the program 			(at 
any layer) can just check if resolv.conf was modified or
	not. Also, signalling N applications isn't very nice. From a
	design viewpoint, it's always better when programs take care of
	their own instead of being notified by someone else: programs
	ought to be adult

	* always reload
	This is a bit too expensive, mostly given the fact that
	resolv.conf rarely changes.

	* periodical reload
	works, but is arbitrary...

	* check at use
	This seems to be the right way. a stat, following symlinks,
	comparing the current (inode, mtime) with the last value, and
	not reloading if both are unmodified, is the way.

2- where to implement?
This seems to be the hard point. If you look at it from the left, you 
have to change the resolver, cos' it where myst is happening. If you 
look from the right, you gotta not touch the resolver, cos' it ain't 
your code. If you take it from behind, you don't see the front, and if 
you put yourself up, you feel the cold clouds...

Should this be in the resolver itlsef, in gethostbystuff, in a new 
wrapper lib or in the app?

Clearly, it is not desirable to have this in applications. This must be 
reusable.

Also, the gethost things don't solve the getmx problem (and the like), 
besides being what I'd call rabbit functions (they proliferate too fast: 
you now have all kinds of functions to do the same thing, but some are 
reentrant, some are IPv6 compatible, some are something else, and in 6 
months, you'll probably have gethostbyname_withmilk).


So it's either in the resolver or in a wrapper. Unfortunately, C isn't 
wrapper friendly. A compromise is to add a new function to the resolver, 
and make it used by defalkt, while not modifying a lot fo the resolver 
code. but once you put your hands in the water, you'd better accept 
you're wet...