RFC: Automatically Reloading /etc/resolv.conf

[Eric van Gyzen]

> Nitpick: the resolver has used poll instead of kqueue for a while, but
> that does not fundamentally change your argument.

I was looking at a 10.2-RELEASE system.  Indeed, I see it using poll on
head.  Thanks.

> Some glibc people think the extra stat may be too slow, though:
> https://sourceware.org/bugzilla/show_bug.cgi?id=984

I added simple code to call stat() on every query and ran a benchmark.
It reduces queries-per-second by 15.87%, so I definitely won't take that
approach.

>> When loading the file, open a kqueue and register for the appropriate
>> events.  Before each query, check for kevents.
> 
> This sounds a bit scary in conjunction with code that bluntly closes
> file descriptors it does not know about.

That's true, but such code would break a variety of other facilities,
such as syslog.  I'll keep this in mind.

> Also, kqueues do not inherit across fork, so the resolver needs some
> sort of atfork handler.

I hadn't thought of that.  Thanks.

>> NetBSD uses this approach.  It mitigates most of the space-cost by using
>> a shared pool of res_state objects, instead of one per thread [that uses
>> the resolver].  On each query, a thread allocates/borrows a res_state
>> from the pool, uses it, and returns it.  So, the number of objects is
>> only the high water mark of the number of threads _concurrently_ issuing
>> resolver queries.
> 
> Is there code that depends on implicit per-thread res_state objects? If
> so, this will break it.

I'm just describing NetBSD's current approach.  I don't plan to adopt
this in FreeBSD.  To answer your question, though, I don't know if such
code exists.

> The NextBSD people have a more efficient alternative notify(3). Using
> that, resolvconf(8) can cause a counter in shared memory to be
> incremented, which can be detected efficiently by the resolver in each
> process. The stat() approach need not wait for this, though.

I didn't know about this.  It sounds rather useful.  Thanks!

Eric