Hi, folks. I've been negligent in trying out the newer iftop releases lately. I just tried to configure 0.15, and found that the POSIX thread test program spins indefinitely on Solaris, blocking the configure.
I'm not very familiar with the POSIX Threads API so I don't know that I can debug this quickly. If I run a truss on the pthread test program, it exits out fairly quickly with a 0 exit value, but if I run it straight it just hangs.
Any thoughts?
On Mon, Nov 17, 2003 at 01:21:09PM -0600, Jonathan Abbey wrote:
Hi, folks. I've been negligent in trying out the newer iftop releases lately. I just tried to configure 0.15, and found that the POSIX thread test program spins indefinitely on Solaris, blocking the configure.
I'm not very familiar with the POSIX Threads API so I don't know that I can debug this quickly. If I run a truss on the pthread test program, it exits out fairly quickly with a 0 exit value, but if I run it straight it just hangs.
Any thoughts?
Yes. `POSIX Threads: Just Say No.'
I changed the test program since the old one didn't work on some operating system (one of the BSDs, I think). The problem was that on some operating systems you need to explicitly call pthread_testcancel for a call to pthread_cancel to succeed.
The reason the test program exists is that there are systems where, with the wrong combination of options, a POSIX threads program will compile and run, but no threads can be created. So the program is supposed to ensure that you can create a thread, that the thread can do some work, that you can cancel the thread, and that you can determine that the thread has quit. It is a testament to the flexibility and robustness of the UNIX APIs that, simply by changing compiler options, it is possible to make a program which fails any one of the above tests.
Can you try this patch:
diff -u -r1.2 pthread.c --- pthread.c 27 Aug 2003 18:29:27 -0000 1.2 +++ pthread.c 17 Nov 2003 19:40:27 -0000 @@ -12,6 +12,7 @@ #include <stdio.h> #include <string.h> #include <time.h> +#include <unistd.h>
static pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER; static pthread_cond_t cond = PTHREAD_COND_INITIALIZER; @@ -23,8 +24,10 @@ pthread_mutex_lock(&mtx); pthread_cond_signal(&cond); pthread_mutex_unlock(&mtx); - while (1) + while (1) { + sleep(1); pthread_testcancel(); + } }
/* Start a thread, and have it set a variable to some other value, then signal
-- which seems to improve things on a Solaris machine here.
On Mon, Nov 17, 2003 at 07:43:37PM +0000, Chris Lightfoot wrote: | Can you try this patch: | | diff -u -r1.2 pthread.c | --- pthread.c 27 Aug 2003 18:29:27 -0000 1.2 | +++ pthread.c 17 Nov 2003 19:40:27 -0000 | @@ -12,6 +12,7 @@ | #include <stdio.h> | #include <string.h> | #include <time.h> | +#include <unistd.h> | | static pthread_mutex_t mtx = PTHREAD_MUTEX_INITIALIZER; | static pthread_cond_t cond = PTHREAD_COND_INITIALIZER; | @@ -23,8 +24,10 @@ | pthread_mutex_lock(&mtx); | pthread_cond_signal(&cond); | pthread_mutex_unlock(&mtx); | - while (1) | + while (1) { | + sleep(1); | pthread_testcancel(); | + } | } | | /* Start a thread, and have it set a variable to some other value, then signal | | | -- which seems to improve things on a Solaris machine | here.
Yes, the configure runs to completion successfully now.
Boy, do I hate racey stuff like this.
jon
| -- | ``Any design problem can be solved by adding a level of indirection, | apart from having too many levels of indirection.'' (Cargill)