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