On 4/25/04 11:06 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> OK, CVS is ready. I unconditionally defined:
>
> -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS
>
> for all ports. It can't hurt if they are not supported, but it makes
> our job easier for porting. It allowed me
> What we really want is for the configure script to _add_ to the existing
> options, and I thought that's what it did. Another bad thing it does is
> if it the supplied port options don't work, it erases them and tries it
> own.
>
> Now, the fact that the configure thread test program worked and
Wes Palmer wrote:
> > OK, I just did some major wacking of the thread stuff and tried it on
> > FreeBSD 4.9. It failed because getpwuid() isn't thread-safe on that
> > platform, and there isn't a getpwuid_r() function, but it did pick up
> > -pthread as a valid option.
> >
> > Please test CVS HEA
On 4/25/04 4:21 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> OK, I just did some major wacking of the thread stuff and tried it on
> FreeBSD 4.9. It failed because getpwuid() isn't thread-safe on that
> platform, and there isn't a getpwuid_r() function, but it did pick up
> -pthread as a vali
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My plan is to have 'configure' run this program as part of its
> > operation,
>
> Peter's not going to be happy with you ;-) Runtime configure tests are
> not part of the Grand Plan --- ideally configure should only have to do
> comp
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My plan is to have 'configure' run this program as part of its
> operation,
Peter's not going to be happy with you ;-) Runtime configure tests are
not part of the Grand Plan --- ideally configure should only have to do
compile and link tests.
[EMAIL PROTECTED] wrote:
> On 4/5/04 8:31 AM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
>
> >>> 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.
> >>
> >>
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 t
Bruce Momjian <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > On 4/4/04 11:43 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> >
> > > 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.
>
Greg Stark wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>
> > [EMAIL PROTECTED] wrote:
> > > On 4/4/04 11:43 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> > >
> > > > OK, new patch applied that causes all threads to wait until the parent
> > > > checks their thread-specific pointers. I r
On 4/4/04 11:43 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> 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.
I'll try to give it a test tonight.
>> Dumb ques
[EMAIL PROTECTED] wrote:
> On 4/4/04 11:43 PM, "Bruce Momjian" <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> I'll try t
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
[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
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 h
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 loo
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 do
[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/$po
> 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
[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
>
20 matches
Mail list logo
