On Fri, Aug 29, 2003 at 05:13:02PM +0100, Chris Lightfoot wrote:
On Fri, Aug 29, 2003 at 05:07:29PM +0100, Paul Warren wrote:
On Fri, Aug 29, 2003 at 04:54:11PM +0100, Chris Lightfoot wrote:
My guess is that it's a difference in the handling of threads (is that vague enough?), and the stuff that makes is quit is <blame-torch action="pass">stuff that Chris wrote</blame-torch>
[...]At a quick guess, I'd say that pcap_loop doesn't call any thread cancellation points, so it hangs on pthread_cancel.
Ah, that's a good point. That said, I'm surprised that quitting works on Mac OS X if that's the problem....
Try this patch: (not absolutely certain about the second parameter to pcap_dispatch; try 1 if -1 doesn't work)
diff -u -r1.44 iftop.c --- iftop.c 2003/05/20 21:14:37 1.44 +++ iftop.c 2003/08/29 16:10:06 @@ -528,7 +528,9 @@ /* packet_loop:
- Worker function for packet capture thread. */
void packet_loop(void* ptr) {
- pcap_loop(pd,-1,(pcap_handler)packet_handler,NULL);
- /* Make sure that this thread is cancellable. */
- while (pcap_dispatch(p, -1, (pcap_handler)packet_handler, NULL) != -1)
pcap_testcancel();}
ITYM pthread_testcancel, and that'll nead the thread handle.
(I should say that I don't recall being the one to put the PCAP stuff in a thread. I have a horror of threads anyway....)
No. I don't understand threads, but I managed to figure out just enough to get them to start in different threads. Obviously, I couldn't then figure out how to make the stop again - you fixed that bit, and therefore claim ownership of that functionality ;-) It may be far less broken than when you first touched it, but you were the last one to touch it...
Paul