The only thing I've asked you not to report is spurious messages after you kill ntop. And that's the only report(s) that we're discussing here.
The reason for not bothering is simply because - when you use a blunt force kill, vs. the programmed shutdown - there's no way to prevent problems - it's inherent in the POSIX threading model. See the kill signal can be delivered to ANY of the threads, not just the one that set the handler. So you either write a lot of very complex logic, where whomever gets the signal records it and then resumes, and then each thread when it wakes up in the normal course of it's processing handles the signal - "Oh, we're ending, better shutdown cleanly", leading to a controlled cascade of shutdown. The problem is that the application then doesn't end immediately. In the case of ntop, it could be as much as 5 minutes before we're down after a control-c. Or you just close things up as quickly and cleanly as is reasonably possible and live with some fallout. The fallout is that there are some protective messages generated based on conditions which - during a normal run - would be indicative of a problem. Since we are shutting down, they're (probably) not, and even if they are, there's nothing we can do other than a few bandaids that cost processing time in the far more common normal cases. -----Burton -----Original Message----- From: Markus Rehbach [mailto:[EMAIL PROTECTED] Sent: Monday, September 08, 2003 12:28 AM To: [EMAIL PROTECTED] Subject: Re: [Ntop-dev] **ERROR** accessMutex() called 'scanIdleLoop' with an UN-INITIALIZED mutex [EMAIL PROTECTED]:487] OK. Nor more Ctl-C. I thought that it is an indicator that there's something wrong internally. Concerning the reported 'hang' of ntop I have no other hint in the logs whats going wrong. And without the hang the messages are not there. But if it is not interesting that ntop hangs internally i do not know what's worth reporting. It's 1kByte dubious traffic only for a DOS on ntop (generated with tcpsic). Shall I stop testing? Shall I not report it? Not a problem. Sorry for your inconveniences Markus _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
