> Maybe the signal handler is doing something unsafe. That's not exactly it; or at least when thinking of it that way I didn't understand the full problem.
The signal can go off when the application is in the middle of malloc(), for example. Not only can the signal handler not call malloc, but we can't do anything on the stack until the signal handler returns and the malloc() call completes. One option is to not do anything on the stack, but rather to just exit with a failure code. That would almost be OK if you assume timeouts are very rare, but they're probably not. Therefore the signal handler has to return, and we have to detect the expired timeout some other way. Simply using select() on the calls, or even just detecting EINTR from an alarm might be enough. The catch is name resolution. I know of no portable way to set a timeout on gethostbyname(), and the default is pretty long. It would be good to cover this case, since it's reasonably common for e.g. a laptop to be unable to reach its nameserver. It's impossible to avoid this using signals; if we interrupt the resolver it may leave things in an arbitrary mess. (Which should have been obvious...) There are a few options: 0- just suffer; or rather tell people to fix their nameserver or turn down the timeout in resolv.conf 1- use resolv.h, which can take a timeout but might be nonportable 2- use an asynchronous DNS library; should be easy but adds another dependency and/or thing that must be bundled 3- run lookups in a separate process, which can be killed off (a bit gross) I guess #0 is probably the best thing. -- Martin __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/distcc
