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

From Lee Kindness
Subject Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Date
Msg-id 15901.37971.681172.613637@kelvin.csl.co.uk
Whole thread Raw
In response to Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Tom,

Tom Lane writes:
 > Lee Kindness <lkindness@csl.co.uk> writes:
 > > + #define _THREAD_SAFE
 > > + #define _REENTRANT
 > > + #define _POSIX_PTHREAD_SEMANTICS
 > What is this stuff, and why isn't it wrapped in any sort of
 > platform-specific test?  If it's needed, why is it in only one .c
 > file?

It's actually in libpq-int.h too... The correct way for this is to
compile with the compilers specific thread flags, however the downside
to this has already been discussed. Depending on the system one, or a
combination of those flags will turn on some magic such as errno being
a function call rather than a global variable. This is needed to make
the library thread safe.

On a second look libpq-int.h isn't the best place for this (hence it
also appears in one of the C files), it needs to be done in each C
file before any of the system headers are included - a libpq-threads.h
header? Would this be ok?

Do do things 100% right we'd need to detect compiler thread flags and
compile with them...

 > Also, haven't you broken SOCK_STRERROR for the Windows case?

Sorry, I seem to have forgotton to update the prototype in win32.h to
match the updated function. Updated diff attached (and online).

Lee.


Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] PostgreSQL libraries - PThread Support, but not use...
Next
From: Peter Eisentraut
Date:
Subject: Re: more adequate usage msg: pg_controldata.diff