Re: [HACKERS] PostgreSQL libraries - PThread Support, but - Mailing list pgsql-patches

From Lee Kindness
Subject Re: [HACKERS] PostgreSQL libraries - PThread Support, but
Date
Msg-id 15906.45488.371123.926993@kelvin.csl.co.uk
Whole thread Raw
In response to Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...  (Lee Kindness <lkindness@csl.co.uk>)
Responses Re: [HACKERS] PostgreSQL libraries - PThread Support, but  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] PostgreSQL libraries - PThread Support, but  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] PostgreSQL libraries - PThread Support, but  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] PostgreSQL libraries - PThread Support, but  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: [HACKERS] PostgreSQL libraries - PThread Support, but  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-patches
Patch attached, along with new libpq-reentrant.c and libpq-reentrant.h
files for src/interfaces/libpq.

Also at http://services.csl.co.uk/postgresql/

Thanks, Lee.

Lee Kindness writes:
 > Ok guys, I propose that the new libpq diff and 2 source files which
 > i'll soon send to pgsql-patches is applied to the source. This diff is
 > a cleaned up version of the previous version with the wrapper
 > functions moved out into their own file and more comments added. Also
 > the use of crypt_r() has been removed (not worth the effort), the
 > cpp defines have been renamed to be consistent with each other and
 > Tom's concerns with loose #defines has been partly addressed.
 >
 > This diff does not include any configure changes. I plan to tackle
 > this separately ASAP, and hopefully produce something more acceptable.
 >
 > I will add checks for appropriate compiler thread flags (for compiling
 > libpq, and alow the removal of #defines in libpq-reentrant.h), and
 > link flags & libs (for a planned threaded libpq test program and
 > renentrant ecpg library). If a thread environment is found then check
 > for the reentrant functions will be done.
 >
 > Looking at various open source projects configure.in files there seems
 > to be little commonality in the thread test macros (telp gratefully
 > accepted!), I currently think that something like the approach used by
 > glib is most suitable (switch on OS).
 >
 > All sound acceptable?
 >
 > Thanks, Lee.
 >
 > Peter Eisentraut writes:
 >  > Lee Kindness writes:
 >  >
 >  > > Patches attached to make libpq thread-safe, now uses strerror_r(),
 >  > > gethostbyname_r(), getpwuid_r() and crypt_r() where available. Where
 >  > > strtok() was previously used strchr() is now used.
 >  >
 >  > AC_TRY_RUN tests are prohibited.  Also, try to factor out some of these
 >  > huge tests into separate macros and put them into config/c-library.m4.
 >  > And it would be nice if there was some documentation about what was
 >  > checked for.  If you just want to check whether gethostbyname_r() has 5 or
 >  > 6 arguments you can do that in half the space.


Attachment

pgsql-patches by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: pg_get_constraintdef patch #2
Next
From: Neil Conway
Date:
Subject: fix broken regression tests