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

[Lennart Poettering]

On Wed, 23.01.13 12:35, Dan Williams (dcbw at redhat.com) wrote:

> > >>> 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.

Yeah, signal handlers are really hard to get right. I am pretty sure
that if somebody took the time to go through the Fedora packages and
would just check how many signal handlers forget to save/restore errno
and write patches for those he'd get himself way up in the Ohloh
statistics of people with the most patches in various projects. He'd
probably even be able to get his name into a number of CVEs as a side
effect...

Lennart

-- 
Lennart Poettering - Red Hat, Inc.