I found the glibc-users mailing list. They explained the problem to me. As
far as I can tell, there isn't a clean fix.
The basic problem is that signal handlers can't legally call many routines.
It's similar to the thread-safe issue but not mentioned on individual man
pages. From signal (7):
A signal handler function must be very careful, since processing else-
where may be interrupted at some arbitrary point in the execution of
the program. POSIX has the concept of "safe function". If a signal
interrupts the execution of an unsafe function, and handler calls an
unsafe function, then the behavior of the program is undefined.
That is followed by a list of safe functions.
If you longjmp out of the signal handler, you are still in the restricted
context and can only call safe functions. The glibc version of th eman page
for setjmp/longjmp has been updated to make that clearer. I don't know how
long it takes that to migrate to what distros distribute.
If you want to write solid code, longjmp-ing out of a signal handler is
basically a no-no. If you want to do that, you have to go through your code
and mask interrupts every time you call a function that is not signal-safe or
when you call in to a library/package which might call an unsafe function.
An alternative is for the interrupt handler to just set a flag and teach the
main code to bail from loops if the flag is set. That works as long as you
don't call anything that takes a long time on a human scale. Many routines
that might take a while return EINTR if they get interrupted by a signal.
Unfortunately, getnameinfo doesn't work that way.
Another approach is to put the getnameinfo in a different thread and use
pthread_cancel. Canceling has similar problems so the thread has to mask
getting canceled at the wrong times which means waiting for getnameinfo to
finish. (But since our thread wouldn't be doing anything else, there is no
point in canceling it.) So we would have to set things up so the thread gets
abandoned and cleans up after itself. I'm sure I could write that code, but
it seems unreasonably complicated.
My plan is to set a flag and wait for getnameinfo to finish, and then try it
to see how annoying the wait is. If it takes too long, I'll consider the
separate thread approach. Now I have to find (and test) all the places where
it should check the flag.
--
These are my opinions. I hate spam.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
