Re: [GENERAL] thread_test.c problems
Bruce Momjian wrote:
> > I did a cvs update, make, then rebuilt and tested thread_test. I ran it
> > about 120 times and got "GETHOSTBYNAME_THREADSAFE=yes" almost all of the
> > time. I got "GETHOSTBYNAME_THREADSAFE=no" three times. The other two were
> > always "yes".
>
> Yep, I can reproduce this on BSD/OS too, so it must be something wrong
> with my program. I see:
>
> $ for X in `jot 1000`; do thread_test |grep -10 '=no' && echo $X;
> done|less
> 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
> 919
>
> I bet the problem is that I am accessing thread-specific pointers after
> the thread exits. It is possible thread 1 completes before thread2 gets
> to the getpwuid and gethostbyname tests, and then reuses the
> thread-specific pointer. Let me work on a patch and email it to you in
> a few minutes.
OK, new patch applied that causes all threads to wait until the parent
checks their thread-specific pointers. I ran 1000 tests and all passed.
Hopefully it will good for you too.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/tools/thread/thread_test.c
===
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.12
diff -c -c -r1.12 thread_test.c
*** src/tools/thread/thread_test.c 5 Apr 2004 02:22:14 - 1.12
--- src/tools/thread/thread_test.c 5 Apr 2004 05:40:13 -
***
*** 40,45
--- 40,48
volatile int errno1_set = 0;
volatile int errno2_set = 0;
+ volatile int thread1_done = 0;
+ volatile int thread2_done = 0;
+
char *strerror_p1;
char *strerror_p2;
***
*** 49,57
struct hostent *hostent_p1;
struct hostent *hostent_p2;
! pthread_mutex_t singlethread_lock1 = PTHREAD_MUTEX_INITIALIZER;
! pthread_mutex_t singlethread_lock2 = PTHREAD_MUTEX_INITIALIZER;
!
int main(int argc, char *argv[])
{
pthread_t thread1,
--- 52,59
struct hostent *hostent_p1;
struct hostent *hostent_p2;
! pthread_mutex_t init_mutex = PTHREAD_MUTEX_INITIALIZER;
!
int main(int argc, char *argv[])
{
pthread_t thread1,
***
*** 73,82
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'\n\
defines to your template/$port file before compiling this program.\n\n"
);
pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1, NULL);
pthread_create(&thread2, NULL, (void * (*)(void *)) func_call_2, NULL);
! pthread_join(thread1, NULL);
! pthread_join(thread2, NULL);
printf("Add this to your template/$port file:\n\n");
--- 75,89
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'\n\
defines to your template/$port file before compiling this program.\n\n"
);
+
+ /* Hold lock until we are ready for the child threads to exit. */
+ pthread_mutex_lock(&init_mutex);
+
pthread_create(&thread1, NULL, (void * (*)(void *)) func_call_1, NULL);
pthread_create(&thread2, NULL, (void * (*)(void *)) func_call_2, NULL);
!
! while (thread1_done == 0 || thread2_done == 0)
! getpid(); /* force system call */
printf("Add this to your template/$port file:\n\n");
***
*** 94,100
--- 101,112
printf("GETHOSTBYNAME_THREADSAFE=yes\n");
else
printf("GETHOSTBYNAME_THREADSAFE=no\n");
+
+ pthread_mutex_unlock(&init_mutex); /* let children exit */
+ pthread_join(thread1, NULL);/* clean up children */
+ pthread_join(thread2, NULL);
+
return 0;
}
***
*** 110,116
fprintf(stderr, "could not generate failure for create file in
/tmp, exiting\n");
exit(1);
}
! /* wait for other thread to set errno */
errno1_set = 1;
while (errno2_set == 0)
getpid(); /* force system call */
--- 122,132
fprintf(stderr, "could not generate failure for create file in
/tmp, exiting\n");
exit(1);
}
! /*
!* Wait for other thread to set errno.
!* We can't use thread-specific locking here because it might
!* affect errno.
!*/
errno1_set = 1;
while (errno2_set == 0)
getpid
Re: [GENERAL] thread_test.c problems
[EMAIL PROTECTED] wrote: > On 4/4/04 7:28 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote: > > > OK, I know the cause of this. The problem is that sometimes hostnames > > don't resolve, and the bigger problem is that it requires an internet > > connection to run the tests. The attached patch tests for 'localhost' > > and your local hostname, so it should work reliably. > > I did a cvs update, make, then rebuilt and tested thread_test. I ran it > about 120 times and got "GETHOSTBYNAME_THREADSAFE=yes" almost all of the > time. I got "GETHOSTBYNAME_THREADSAFE=no" three times. The other two were > always "yes". Yep, I can reproduce this on BSD/OS too, so it must be something wrong with my program. I see: $ for X in `jot 1000`; do thread_test |grep -10 '=no' && echo $X; done|less 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 919 I bet the problem is that I am accessing thread-specific pointers after the thread exits. It is possible thread 1 completes before thread2 gets to the getpwuid and gethostbyname tests, and then reuses the thread-specific pointer. Let me work on a patch and email it to you in a few minutes. > I did verify that both the "volatile" and "localhost" changes were in there. > > Dumb question... Why would you not always use the _r functions if they > exist? Yes, we do use *_r functions in 7.5 if they exist, but in 7.4.X, I think we use the non-R if we can, though we actually just use getaddrinfo() in 7.4.X if it exists. Basically, the threading tests are still in flux, as you can see, in 7.4.X. It works, but it isn't 100% configure perfect yet. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] thread_test.c problems
On 4/4/04 7:28 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote: > OK, I know the cause of this. The problem is that sometimes hostnames > don't resolve, and the bigger problem is that it requires an internet > connection to run the tests. The attached patch tests for 'localhost' > and your local hostname, so it should work reliably. I did a cvs update, make, then rebuilt and tested thread_test. I ran it about 120 times and got "GETHOSTBYNAME_THREADSAFE=yes" almost all of the time. I got "GETHOSTBYNAME_THREADSAFE=no" three times. The other two were always "yes". I did verify that both the "volatile" and "localhost" changes were in there. Dumb question... Why would you not always use the _r functions if they exist? Wes ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] RPM init-script: Why the locale setting?
Troels Arvin <[EMAIL PROTECTED]> writes: > In the init-script contained in the RPMs downloadable from the PostgreSQL > site (I checked the one for Fedora), an explicit locale is set before > running initdb. - And the explicit locale is not "C". Only if you don't have a sysconfig file: # Just in case no locale was set, use en_US [ ! -f /etc/sysconfig/i18n ] && echo "LANG=en_US" > $PGDATA/../initdb.i18n I agree though that it seems like a bad choice to default to en_US rather than C. Lamar, any reason why it's like that? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] thread_test.c problems
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > [EMAIL PROTECTED] wrote: > > have you tried adding a volatile keyword to the > > int volatile errno1_set = 0; > > int volatile errno2_set = 0; > > > > I have applied the following patch to CVS head which does a getpid() in > > the loop, rather than nothing. > > That does not cure the bug identified by wespvp. It may make it a > little less likely that the compiler will choose to optimize out the > loop test, but only adding "volatile" really fixes the problem in > a language-standard-compliant way. Thanks, 'volatile' added to the thread-specific errno variables: volatile int errno1_set = 0; volatile int errno2_set = 0; -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] thread_test.c problems
Bruce Momjian <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] wrote: > have you tried adding a volatile keyword to the > int volatile errno1_set = 0; > int volatile errno2_set = 0; > > I have applied the following patch to CVS head which does a getpid() in > the loop, rather than nothing. That does not cure the bug identified by wespvp. It may make it a little less likely that the compiler will choose to optimize out the loop test, but only adding "volatile" really fixes the problem in a language-standard-compliant way. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] thread_test.c problems
[EMAIL PROTECTED] wrote:
> Add this to your template/$port file:
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=no
>
> [g4:src/tools/thread] wp% ./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=yes
> GETHOSTBYNAME_THREADSAFE=yes
>
>
> It returns mostly 'yes' for all three, but sometimes returns 'no' for the
> last one. I get the same conflicting results whether I run with one or two
> CPU's enabled.
>
OK, I know the cause of this. The problem is that sometimes hostnames
don't resolve, and the bigger problem is that it requires an internet
connection to run the tests. The attached patch tests for 'localhost'
and your local hostname, so it should work reliably.
> Similarly, the 7.4.2 release is showing:
>
> % ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> All your non-*_r functions are thread-safe.
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=no
>
>
> % ./thread_test
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> Your gethostbyname() is _not_ thread-safe
> Not all non-*_r functions are thread-safe.
> Add this to your template/$port file:
>
> NEED_REENTRANT_FUNCS=yes
>
>
>
> I assume the safe bet is GETHOSTBYNAME_THREADSAFE=no for the tip and
> NEED_REENTRANT_FUNCS=yes for 7.4.2? Can I rely on the other two being
> 'yes', or should they be set to 'no' also?
Yes, that is the safe bet on 7.4.X. 7.5 will use individual entries for
each function, and in fact we might have this all merged into configure
by then anyway.
>
> Based on the linux template and the output of thread_test, I have set up the
> darwin template and compiled the CVS tip code on Mac OS X 10.3.3 with:
>
>
>
> # Apple's cpp-precomp seems a tad broken, so don't use it
> # (Note: on OS X before 10.2, you might need -traditional-cpp instead)
> #CC="$CC -no-cpp-precomp"
>
> # Select appropriate semaphore support
> USE_NAMED_POSIX_SEMAPHORES=1
>
> # tools/thread/thread_test must be run
> THREAD_SUPPORT=yes
> THREAD_CPPFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
> THREAD_LIBS="-lpthread"
>
> STRERROR_THREADSAFE=yes
> GETPWUID_THREADSAFE=yes
> GETHOSTBYNAME_THREADSAFE=no
>
> #NEED_REENTRANT_FUNCS=yes
>
>
>
>
> I commented out the 'CC="$CC -no-cpp-precomp"' line and did not get any
> compile errors. Mac OS X 10.3.3 uses GCC 3.3. I know something changed
> between Mac OS X 10.2 and 10.3 regarding precomp (they also upgraded from
> gcc 2.96 to 3.3). It seems to compile ok on 10.3 regardless of the setting
> of this parameter, so unless it is important to have it enabled when
> possible, it is probably best to leave it off for backwards compatibility?
>
> I also added all of the thread lines starting with the comment '#
> tools/thread/thread_test must be run' based on the output of thread_test.
> The released PostgreSQL 7.4.2 says I should use 'NEED_REENTRANT_FUNCS=yes'.
Yes, in 7.4.X, you only need that single entry.
Thanks for the testing.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: src/tools/thread/thread_test.c
===
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.10
diff -c -c -r1.10 thread_test.c
*** src/tools/thread/thread_test.c 4 Apr 2004 17:23:54 - 1.10
--- src/tools/thread/thread_test.c 5 Apr 2004 01:22:04 -
***
*** 35,40
--- 35,42
void func_call_1(void);
void func_call_2(void);
+ char myhostname[MAXHOSTNAMELEN];
+
int errno1_set = 0;
int errno2_set = 0;
***
*** 61,66
--- 63,74
return 1;
}
+ if (gethostname(myhostname, MAXHOSTNAMELEN) != 0)
+ {
+ fprintf(stderr, "can not get local hostname, exiting\n");
+ exit(1);
+ }
+
printf("\
Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'\n\
defines to your template/$port file before compiling this program.\n\n"
***
*** 128,135
passwd_p1 = NULL; /* force thread-safe failure report */
}
! hostent_p1 = gethostbyname("www.yahoo.com");
! p = gethostbyname("www.weather.com");
if (hostent_p1 != p)
{
printf("Your gethostbyname() changes the static memory area between
c
Re: [GENERAL] RPM init-script: Why the locale setting?
On Sun, 4 Apr 2004, Troels Arvin wrote: > Hello, > > In the init-script contained in the RPMs downloadable from the PostgreSQL > site (I checked the one for Fedora), an explicit locale is set before > running initdb. - And the explicit locale is not "C". > > This means that a PostgreSQL installation will not use indexes for LIKE > queries (I just ran into this). See > http://www.postgresql.org/docs/faqs/FAQ.html#4.8 Technically you should be able to use an index in the appropriate *_pattern_ops opclass, but yes, normal indexes aren't used. > I suggest that the init-script be rewritten so that LANG and LC_ALL are > unset before initdb is run (which happens the first time PostgreSQL is > started after the RPM-based installation). Wouldn't this get in the way of having the server "do the right thing" when in a locale that doesn't collate by "C" rules? ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[GENERAL] Version 1.0.0.4 released
Hi all, Version 1.0.0.4 of the Postgresql OLE DB provider for Windows was just released. Get it at http://gborg.postgresql.org/project/oledb/download/download.php?branch=devel. Release includes a source only version, and a compiled version. The compiled version will require libpq (precompiled version available at http://gborg.postgresql.org/project/oledb/download/download.php). New features since 1.0.0.1 (previous released version): * Correctly reports cells with NULL values. * Most numeric and textual types handled * Generic infrastructure for handling new types, including types for which only the name is known at compile time (user-defined types). * Transactions are now supported (though row-updates are not yet supported). All in all, this version should provide the basic functionality for many day to day uses. The provided compiled version is of a Debug build, which means that stepping outside of the handled path will probably result in ASSERTS. The provider requires libpq version 7.4 or greater, and a backend of version 7.4 or greater. The later requirement may be relaxed in the future. -- Shachar Shemesh Lingnu Open Systems Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] RPM init-script: Why the locale setting?
On 04/04/2004 21:48 Troels Arvin wrote: Hello, In the init-script contained in the RPMs downloadable from the PostgreSQL site (I checked the one for Fedora), an explicit locale is set before running initdb. - And the explicit locale is not "C". This means that a PostgreSQL installation will not use indexes for LIKE queries (I just ran into this). See http://www.postgresql.org/docs/faqs/FAQ.html#4.8 No. It says that [normal] indexes won't be used for: select foo from bar where col like '%abc'; or select foo from bar where col like '%abc%'; or ILIKE is used. And even then you can use a functional index of the form CREATE INDEX tabindex ON tab (lower(col)); I suggest that the init-script be rewritten so that LANG and LC_ALL are unset before initdb is run (which happens the first time PostgreSQL is started after the RPM-based installation). I'll admit that I don't know what effect this would have but I'm interested to find out. regards -- Paul Thomas +--+-+ | Thomas Micro Systems Limited | Software Solutions for Business | | Computer Consultants | http://www.thomas-micro-systems-ltd.co.uk | +--+-+ ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[GENERAL] RPM init-script: Why the locale setting?
Hello, In the init-script contained in the RPMs downloadable from the PostgreSQL site (I checked the one for Fedora), an explicit locale is set before running initdb. - And the explicit locale is not "C". This means that a PostgreSQL installation will not use indexes for LIKE queries (I just ran into this). See http://www.postgresql.org/docs/faqs/FAQ.html#4.8 I suggest that the init-script be rewritten so that LANG and LC_ALL are unset before initdb is run (which happens the first time PostgreSQL is started after the RPM-based installation). -- Greetings from Troels Arvin, Copenhagen, Denmark ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] thread_test.c problems
> I have applied the following patch to CVS head which does a getpid() in > the loop, rather than nothing. getpid() should force a system call, > which will make it more likely for the other thread to get CPU time and > complete its tests. Works for me... However, there seems to be a reliability problem with the results: [g4:src/tools/thread] wp% ./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=yes GETHOSTBYNAME_THREADSAFE=no [g4:src/tools/thread] wp% ./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=yes GETHOSTBYNAME_THREADSAFE=yes It returns mostly 'yes' for all three, but sometimes returns 'no' for the last one. I get the same conflicting results whether I run with one or two CPU's enabled. Similarly, the 7.4.2 release is showing: % ./thread_test Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS' defines to your template/$port file before compiling this program. All your non-*_r functions are thread-safe. Add this to your template/$port file: NEED_REENTRANT_FUNCS=no % ./thread_test Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS' defines to your template/$port file before compiling this program. Your gethostbyname() is _not_ thread-safe Not all non-*_r functions are thread-safe. Add this to your template/$port file: NEED_REENTRANT_FUNCS=yes I assume the safe bet is GETHOSTBYNAME_THREADSAFE=no for the tip and NEED_REENTRANT_FUNCS=yes for 7.4.2? Can I rely on the other two being 'yes', or should they be set to 'no' also? Based on the linux template and the output of thread_test, I have set up the darwin template and compiled the CVS tip code on Mac OS X 10.3.3 with: # Apple's cpp-precomp seems a tad broken, so don't use it # (Note: on OS X before 10.2, you might need -traditional-cpp instead) #CC="$CC -no-cpp-precomp" # Select appropriate semaphore support USE_NAMED_POSIX_SEMAPHORES=1 # tools/thread/thread_test must be run THREAD_SUPPORT=yes THREAD_CPPFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS" THREAD_LIBS="-lpthread" STRERROR_THREADSAFE=yes GETPWUID_THREADSAFE=yes GETHOSTBYNAME_THREADSAFE=no #NEED_REENTRANT_FUNCS=yes I commented out the 'CC="$CC -no-cpp-precomp"' line and did not get any compile errors. Mac OS X 10.3.3 uses GCC 3.3. I know something changed between Mac OS X 10.2 and 10.3 regarding precomp (they also upgraded from gcc 2.96 to 3.3). It seems to compile ok on 10.3 regardless of the setting of this parameter, so unless it is important to have it enabled when possible, it is probably best to leave it off for backwards compatibility? I also added all of the thread lines starting with the comment '# tools/thread/thread_test must be run' based on the output of thread_test. The released PostgreSQL 7.4.2 says I should use 'NEED_REENTRANT_FUNCS=yes'. Wes ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] thread_test.c problems
[EMAIL PROTECTED] wrote:
> On 4/4/04 12:33 AM, "joseph speigle" <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> That cures the problem on all systems. What needs to be done to get this
> updated in the tip?
>
> > 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
>
> I don't know what is different, but I've tried it on RH 7.2, RH AS 3.0, and
> Mac OS X. All hang in an infinite loop with the tip version of
> thread_test.c, and all work if I add 'volatile' to the definitions of
> errno1_set and errno2_set.
>
> There's still the question of which version of the program is giving the
> right answers - the 7.4.2 version or the tip version?
I have applied the following patch to CVS head which does a getpid() in
the loop, rather than nothing. getpid() should force a system call,
which will make it more likely for the other thread to get CPU time and
complete its tests.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
Index: thread_test.c
===
RCS file: /cvsroot/pgsql-server/src/tools/thread/thread_test.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -c -c -r1.9 -r1.10
*** thread_test.c 28 Mar 2004 02:37:31 - 1.9
--- thread_test.c 4 Apr 2004 17:23:54 - 1.10
***
*** 105,111
/* wait for other thread to set errno */
errno1_set = 1;
while (errno2_set == 0)
! /* loop */;
if (errno != EEXIST)
{
fprintf(stderr, "errno not thread-safe; exiting\n");
--- 105,111
/* wait for other thread to set errno */
errno1_set = 1;
while (errno2_set == 0)
! getpid(); /* force system call */
if (errno != EEXIST)
{
fprintf(stderr, "errno not thread-safe; exiting\n");
***
*** 128,135
passwd_p1 = NULL; /* force thread-safe failure report */
}
! hostent_p1 = gethostbyname("yahoo.com");
! p = gethostbyname("slashdot.org");
if (hostent_p1 != p)
{
printf("Your gethostbyname() changes the static memory area between
calls\n");
--- 128,135
passwd_p1 = NULL; /* force thread-safe failure report */
}
! hostent_p1 = gethostbyname("www.yahoo.com");
! p = gethostbyname("www.weather.com");
if (hostent_p1 != p)
{
printf("Your gethostbyname() changes the static memory area between
calls\n");
***
*** 151,157
/* wait for other thread to set errno */
errno2_set = 1;
while (errno1_set == 0)
! /* loop */;
if (errno != ENOENT)
{
fprintf(stderr, "errno not thread-safe; exiting\n");
--- 151,157
/* wait for other thread to set errno */
errno2_set = 1;
while (errno1_set == 0)
! getpid(); /* force system call */
if (errno != ENOENT)
{
fprintf(stderr, "errno not thread-safe; exiting\n");
***
*** 174,181
passwd_p2 = NULL; /* force thread-safe failure report */
}
! hostent_p2 = gethostbyname("google.com");
! p = gethostbyname("postgresql.org");
if (hostent_p2 != p)
{
printf("Your gethostbyname() changes the static memory area between
calls\n");
--- 174,181
passwd_p2 = NULL; /* force thread-safe failure report */
}
! hostent_p2 = gethostbyname("www.google.com");
! p = gethostbyname("www.postgresql.org");
if (hostent_p2 != p)
{
printf("Your gethostbyname() changes the static memory area between
calls\n");
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
