k...@roeckx.be said: > Why do you set up a signal handler for this, and don't let the OS take care > of it?
> Or alternativly, just call _exit() from the signal handler. It's not trying to exit, just get out of a long running command. ntpq has two long-running commands. (Maybe more.) One is peers (which has many variants). Normally, it tries to translate the IP address of the slot to a name. The other is mrulist. It runs in two passes. The first pass collects the data. Since slots may get updated while being collected there is the possibility to go back and fetch them again. The second pass sorts and prints things out. With two passes, you would like ^C during the collect pass to stop collecting and print out what it has. So the ^C handler just sets a flag and the collect loop stops collecting. The print pass resets the flag as it starts, then watches the flag so another ^C will stop printing. I think I could avoid the longjmp by having the peers loop check the flag. I haven't checked to see if there are any other commands that might run too long. -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
