Re: Threading for 7.5

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Threading for 7.5
Date: 2004-04-24 00:09:21
Message-ID: 200404240009.i3O09Lm15608@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


I have completed most of the thread changes listed below.

I have added automatic thread compile/link flag detection via configure
from the URL listed below. I have kept per-platform customization that
was used in the past. Please let me know of the new flag usage (like
-pthread) makes your platform's template flags unneeded.

I have also added code to the bottom of configure to run
src/tools/thread_test for threaded builds and throw an error if the
platform doesn't support threads.

I have greatly improved the thread test program. It now does only the
tests that are required for that platform, rather than all thread
functions we might need.

I talked to Peter via chat and he seemed to be OK with it. He didn't
like running the test program from initdb or putting it in /bin, and
wanted it done as part of configure.

I am sure this will need adjustment, but for now, I think it looks good.

I have also added a doc mention that folks run the thread test program
if they are experiencing problems with threading.

Folks, please test and let me know how it works for your platform.

[ I think for Unixware we are going to need to use the thread flags for
building all binaries. It will be easy to do. Larry, you read to test
a patch?]

---------------------------------------------------------------------------

pgman wrote:
> As you know, we had libpq and ecpg threading available in 7.4 via a
> configure flag.
>
> However, threading required users to report their platform's configure
> flags (something better done by configure) and run a thread test program
> (src/tools/thread/thread_test).
>
> For 7.5, I want to use:
>
> http://www.gnu.org/software/ac-archive/htmldoc/acx_pthread.html
>
> that Jan found that is a plug-in for configure to determine thread
> flags. As long as it has the existing platform flags we know about,
> this will be a better way to determine threading flags.
>
> The thread-test program is works, but it tests only one version of each
> operating system. Ideally is should be run on the build/install
> machine, rather than have a per-port value. I talked via chat with
> Peter on this, and running this from configure again only tests the
> current library, and doesn't handle cross-compiling or cases where a
> different version of the dynamic library is used for binary
> distributions.
>
> The basic problem is that thread_test tests _how_ functions get their
> results (thread-safe or not), and not the actual input/output of the
> function.
>
> I want to do away with per-platform testing for thread_test. If the
> platform supports threading, it should pass that test. I have updated
> its output to be cleaner:
>
> Make sure you have added any needed 'THREAD_CPPFLAGS' and 'THREAD_LIBS'
> defines to your template/$port file before compiling this program.
>
> errno is thread-safe
>
> Your system uses strerror() which is thread-safe.
> Your system has getpwuid_r(), so it doesn't use getpwuid().
> Your system has getaddrinfo(), so it doesn't use gethostbyname()
> or gethostbyname_r().
>
> YOUR PLATFORM IS THREADSAFE
>
> It reports the system as thread safe or not thread-safe. I think we can
> just tell folks to run that test if they are going to use threads or if
> they are having problems with threads. We can mark platform versions
> that are _not_ thread safe, rather than enable platforms only after they
> have passed the test. If it doesn't pass, the platform is broken for
> threads. The idea is that any platform that supports threads _should_
> pass the test. Assuming that many will fail is not efficient for us,
> and perhaps not reliable either.
>
> Peter asked about binary-only distributions, and how they would run the
> thread test program. Perhaps when threading is enabled in configure, we
> should actually install the thread test program as pg_thread_test in
> /bin along with the other PostgreSQL binaries. Folks who want to use
> threads should run that program first to test things.
>
> With these changes, all platforms should be able to enable threads, and
> we will not have to collect per-platform thread reports for 7.5, except
> collect platform versions that are not thead-safe and put those tests in
> the template files.
>
> Comments?
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Browse pgsql-hackers by date

  From Date Subject
Next Message emf 2004-04-24 00:28:42 The case for preserving case.
Previous Message Bruce Momjian 2004-04-23 23:59:41 Re: thread_test.c problems