On Wed, 26 Feb 2003 08:36:24 -0800, Jason R Thorpe
<thorpej@wasabisystems.com> wrote:
> On Wed, Feb 26, 2003 at 11:33:04AM -0500, Perry E. Metzger wrote:
> 
>  > Not everything operates that way. In particular, more and more of our
>  > programs are event driven and block in select, poll, or kevent
>  > anyway, waiting for I/O or other events. Under such circumstances,
>  > checking for changes to resolv.conf is free.
> 
> Right, so, the resolver code in libc doesn't do this.  Therefore,
> a kevent(2) call would be necessary in order to detect a change to
> the file.

This was a facinating thread for me.  The problem domain is small and
something I understand, yet it has all these (to me at least) arcane
interstices.  I'm left with questions.  

1.  Were the libc resolver code completely rewritten to be event driven,
would kqueue be the best choice?  Would that imply far reaching changes
throughout libc?  

2.  Where I can read more about these things as they relate to NetBSD? 
Are there academic articles online that would provide a conceptual
framework?  Or is it just me and the source code on a rainy day?  

3.  What about race conditions?  If I write the file just as the resolver
stats it, what prevents a dirty read of the unclosed file?  

4.  What about a signal?  Is it completely stupid to suggest that the
resolver re-read resolv.conf whenever signal X is received?  I admit, it
doesn't scale very well, and I assume there's a standard answer.  

I gather that having httpd (say) cause the resolver to stat resolv.conf on
every name resolution would introduce nontrivial overhead.  

Thanks for taking the time.  

--jkl