From: | joseph speigle <joe(dot)speigle(at)jklh(dot)us> |
---|---|
To: | PostgreSQL <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: thread_test.c problems |
Date: | 2004-04-04 06:33:49 |
Message-ID: | 20040404063349.GA28745@www.sirfsup.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
wespvp,
have you tried adding a volatile keyword to the
int volatile errno1_set = 0;
int volatile errno2_set = 0;
that should stop while-loop optimizing for cases where the variable is modified in a scope the compiler would be ignorant of, and precludes compiler while-loop optimization. That would then tell you if it was a while loop optimization problem.
As for me on RH 8.0
gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)
sorry, they all run yes/no/no
On Sat, Apr 03, 2004 at 03:40:01PM -0600, wespvp(at)syntegra(dot)com wrote:
> [Sorry, I hit the wrong butt on and sent this earlier before I meant to]
>
> When I try to run thread_test.c from the CVS tip, it hangs in an infinite
> CPU loop on both linux (RedHat AS 3.0, gcc 3.2.3) and Mac OS X 10.3.3 (gcc
> 3.3). I've also tried down to gcc 2.96 on Mac OS X.
>
> If I compile it with -g instead of -O2 on linux, it runs to completion and
> gives me:
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
>
> On Mac OS X, it gives me:
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=yes
>
> If I modify the two while loops
>
> while (errno2_set == 0)
>
> while (errno1_set == 0)
>
> To execute a 'print' statement or a 'time(NULL)' instead of a null loop,
> then it runs to completion with -O2.
>
>
>
> If I run the 7.4.2 released version of thread_test.c, for both platforms I
> get:
>
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=yes
>
> There seems to be two problems
>
> 1. It would appear the compiler is optimizing the while loop to be an
> infinite loop. Other explanations?
>
> 2. The answers both can't be right... On OS X, the 7.4.2 version says
> NEED_REENTRANT_FUNCS=yes, but with the tip version it says all are thread
> safe.
>
>
>
> On linux, the make run (putting 'time(NULL)' in the loop):
>
> make
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -I../../../src/include -D_GNU_SOURCE -c -o
> thread_test.o thread_test.c -MMD
> gcc -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -L../../../src/port
> -Wl,-rpath,/wdisk/wrp/opensrc/as30/local/pgsql7.4.2/lib -lpthread
> thread_test.o -lz -lcrypt -lresolv -lnsl -ldl -lm -lbsd -lpgport -o
> thread_test
> [wrp(at)juniper thread]$ !.
> ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=no
> GETHOSTBYNAME_THREADSAFE=no
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
--
joe speigle
www.sirfsup.com
From | Date | Subject | |
---|---|---|---|
Next Message | Mooney, Ryan | 2004-04-04 06:39:31 | Re: Large DB |
Previous Message | Tom Lane | 2004-04-04 05:44:13 | Re: Recursive FOREIGN KEY? |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2004-04-04 07:51:59 | Re: Function to kill backend |
Previous Message | Mike Mascari | 2004-04-04 06:04:32 | Re: Function to kill backend |