[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Userland API for threaded programs to reload /etc/resolv.conf
> On Nov 1, 2013, at 8:41 AM, Martin Husemann <martin%duskware.de@localhost>
>> On Fri, Nov 01, 2013 at 12:23:58PM +0000, Christos Zoulas wrote:
>> This is not the job of the application. Our resolver handles this just fine.
>> It uses a kqueue to register for file update events to /etc/resolv.conf,
>> and updates itself internally when needed.
> Cool, didn't know that - this is exactly what I described later, even more
> cool that it already is in place.
>> This will not work in a threaded environment and is a step backwards.
> If it does not work, maybe we should add similar traps as for _res?
It is easy to do so; I am just afraid on how many broken applications we'll
have to fix!
>> If you just use getaddrinfo() and getnameinfo() on NetBSD everything
>> will work just fine.
> This is realy great - as the application in question now is forced (via
> stupid autoconfig tricks) to believe that we have no res_ninit(), and all
> the calls are #ifdef'd out.
> So I'll just try to push some comments upstream explaining this and leave
> everything as-is.
Well what should be done probably is to use just 2 entry points in Firefox
(call them ff_getaddrinfo() and ff_getnameinfo() for example) and put all the
ugliness in there for the ones who need it.
> Is this documented in some man pages?
I will add something later today if it is not there already.
Main Index |
Thread Index |