Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Dan Williams]

On Wed, 2013-01-23 at 09:48 -0800, John Reiser wrote:
> On 01/23/2013 09:27 AM, Daniel P. Berrange wrote:
> > On Wed, Jan 23, 2013 at 11:24:25AM -0600, Dan Williams wrote:
> >> On Wed, 2013-01-23 at 02:46 +0100, Lennart Poettering wrote:
> >>> On Mon, 21.01.13 10:25, Daniel P. Berrange (berrange at redhat.com) wrote:
> >>>
> >>>>> The glibc maintainers don't seem to be against this idea and I am
> >>>>> willing to put time into design and implementation.
> >>>>
> >>>> Perhaps I'm misunderstanding what you're after, but doesn't "getaddrinfo_a"
> >>>> already provide an async version of getaddrinfo ?
> >>>>
> >>>>     "Asynchronous Hostname Lookup API"
> >>>>    http://www.akkadia.org/drepper/asynchnl.pdf
> >>>>
> >>>> That said I don't see the reverse - getnameinfo_a
> >>>
> >>> Brrrrh. It's designed around process signal delivery. I am
> >>> shuddering. 
> >>
> >> Ew.  Signals are not an event loop API.  Signals are not an event loop
> >> API.  Signals are not an event loop API.  But apparently that's hard for
> >> some people to understand...
> > 
> > I never claimed it was a nice API, just that it provides an async hostname
> > lookup capability already :-)
> 
> The signal handler can write a packet into a pipe from the process to itself,
> and that can be hooked up to an event loop API.

Clearly.  But then you have to deal with signal handling and all the
things you're not able to do from a signal handler like allocate memory,
figure out any locking that may be required, and deal with signal
handler re-entrancy.  It's much easier for consumers of your library to
give them an API that can be easily integrated into their event loop
using select().  But of course that requires that you design your
library in an asynchronous manner too [1], which is just good practice
anyway so neither you nor your API clients don't have to deal with this
stuff.

Dan

[1] eg, client asks for a name lookup and hands your library a callback
function, your library constructs and sends the DNS request, then gives
control back to the caller and lets them select() on the UDP socket, and
when data is available they call back into your library so you can
handle the response, and when you have one you call the client's
callback