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.
(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.
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.