Re: thread_test.c problems - Mailing list pgsql-general

From Bruce Momjian
Subject Re: thread_test.c problems
Date
Msg-id 200404260344.i3Q3iUN07304@candle.pha.pa.us
Whole thread Raw
In response to thread_test.c problems  (Wes Palmer <Wesley.R.Palmer@syntegra.com>)
Responses Re: thread_test.c problems
List pgsql-general
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 HEAD and report back.  Thanks.
>
> Maybe -lpthread isn't needed on OS X (10.3)?  I built thread_test, which
> compiled without -lpthread and still worked.  How can I be certain
> postgresql built correctly with full thread support?
>
>
>
> % make
> gcc -no-cpp-precomp -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -I../../../src/include   -c -o thread_test.o
> thread_test.c -MMD
> gcc -no-cpp-precomp -O2 -fno-strict-aliasing -Wall -Wmissing-prototypes
> -Wmissing-declarations -D_REENTRANT -D_THREAD_SAFE
> -D_POSIX_PTHREAD_SEMANTICS -L../../../src/port   thread_test.o  -o
> thread_test
>
>
> % otool -L thread_test  (Apple technote says this is the same as "ldd")
> thread_test:
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 71.0.0)
>
>
> % ./thread_test
> Your errno is thread-safe.
> Your system has sterror_r();  it does not need strerror().
> Your system has getpwuid_r();  it does not need getpwuid().
> Your system has getaddrinfo();  it does not need gethostbyname()
>   or gethostbyname_r().
>
> Your platform is thread-safe.

I figured it out.  It turns out that acx_pthread.m4 doesn't test any
more options if the value supplied by the port if it can link to the
function pthread_join.

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 reported
good results means:

    o  threads work with the supplied options
    o  errno is thread-safe

so I think the supplied Darwin options are enough.

Interesting that the acx_pthread.m4 just keep checking options until it
finds one that succeeds, then stops tryinug any more.

I have to think about this.  I think maybe we should add a
PTHREAD_CPPFLAGS to template port files, and just add that in at the
end.

They actually have this little port-specific code:

        case "${host_cpu}-${host_os}" in
                *-aix* | *-freebsd*)     flag="-D_THREAD_SAFE";;
                *solaris* | *-osf* | *-hpux*) flag="-D_REENTRANT";;
        esac

and I think we need to remove that and have the template files handle
such thing.

I will email you when CVS is ready.
--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

pgsql-general by date:

Previous
From:
Date:
Subject: Re: thread_test.c problems
Next
From: "tech tech "
Date:
Subject: Re: PostgreSQL 7.4.2 initdb problem