Re: Flushing output

[Andreas Ericsson <ae () op5 se>]

Nils Magnus wrote:
> Re,
>
> On Sat, May 07, 2005 at 03:06:32PM +0000, grutz wrote:
>
> > Here's something I'd like to see added that would help with rate-limited 
> > testing: really flushing out all the information nmap currently has 
> > about a host when interrupted with a SIGINT. It sucks to have been 
> > scanning 65535 ports on a subnet of 4 machines, have 3 of them be 
> > completed while one just sort of sits there, slowly responding. If you 
> > send nmap a SIGINT (^C) while it's hung on the last machine you don't 
> > get any information in the output other than the scan info. Now you have 
> > to rescan the previous hosts again.
>
>
> That's why I suggested some time ago to introduce a handler for SIGUSR1
> or something that makes nmap flush all data on a current host (or set of
> target hosts) and move on to the next one.

nmap can't handle SIGUSR1 if it wishes to use threads on old linux boxen 
(or new ones which use the LinuxThreads library). In fact, threads and 
signals make a horrible mix whichever way you use them since there's no 
way of telling which thread was where when the signal arrived. The risk 
for deadlocks (or livelocks) is obvious, and implementing something like 
this is not as easy as making "finish_up_and_print_output(int sig)" the 
default sighandler for SIGINT (or any signal, for that matter).

-- 
Andreas Ericsson                   andreas.ericsson () op5 se
OP5 AB                             www.op5.se
Lead Developer


_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev