Siri Dhyan Singh wrote:
Chris Lightfoot wrote:
On Sat, Aug 23, 2003 at 10:06:23AM -0700, Siri Dhyan Singh wrote:
Chris Lightfoot wrote:
Yep. It's a brokenness in Mac OS's POSIX threads routines. I'll try to do a fix later.
(At this point I should say that I think the Mac OS behaviour is in fact standards-compliant, but unhelpful.)
Alright thanks!
I'm fairly lightweight when it comes to C/C++ but I do have a programming background so if there's anything I can do to help please let me know.
Have you tried the two patches I sent? iftop compiles fine on my Mac now but I suspect my version is a little out of sync with 0.13.
I just applied the patches and it seems to be working fine. I supply a n interface of en0 as its OS X and I'm off and running.
A little more background here. Basically on OS X 10.2.6 (and other BSDs I suspect) I'm pulling up a couple of pseudo devices used for tunneling which are probably not appropriate as defaults for iftop. Here's a little patch. My first code contribution to an open source project - a historic moment ;-).
diff -u options.orig options.c --- options.orig Mon Aug 25 15:30:26 2003 +++ options.c Mon Aug 25 15:33:32 2003 @@ -40,6 +40,8 @@ static char *bad_interface_names[] = { "lo:", "lo", + "stf", //pseudo-device 6to4 tunnel interface + "gif", //psuedo-device generic tunnel interface "dummy", "vmnet", NULL /* last entry must be NULL */
Kind Regards,
Siri Dhyan
(Stop reading here if you don't want to know the gory details.)
The background to this problem: different systems need different combinations of compiler options to get working POSIX threads support. Linux and Solaris, in particular, are quite different, and IIRC the compiler options which work on Linux give programs which compile *but when run cannot start threads* on Solaris.
ahh how nice and frustrating :-)
So config/pthread.c is a small test program which spawns a thread which then changes the value of a variable; the controlling thread then cancels the subthread and verifies that the variable's value has changed. This allows us to detect whether we have threads that work at all; the configure script can try compiling this program with various different options until it works.
Unfortunately, on Mac OS X, the program hung while trying to cancel (==kill) the subthread. This was because I had assumed -- incorrectly, it seems -- that the function yield(2) was a cancellation point. While it is (or appears to be) on Linux and Solaris, it isn't in Mac OS X. While this might seem surprising, it apparently conforms to the standard. Slightly more surprisingly, replacing yield() with sleep(1) also caused the thing to hang, which I believe is wrong, since http://www.opengroup.org/onlinepubs/7908799/xsh/threads.html lists sleep as a cancellation point.
The take home message? Threads: Just Say No.
many thanks
-Siri dhyan
iftop-users mailing list iftop-users@lists.beasts.org http://lists.beasts.org/mailman/listinfo/iftop-users