On Wed, 23.01.13 12:35, Dan Williams (dcbw(a)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.