Tom,
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> 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
> fil
Guys, just posted patches for libpq to address thread-safe issues. Now
uses strerror_r(), gethostbyname_r(), getpwuid_r() and crypt_r() where
available. Passes all tests on Linux and Solaris.
Any comments let me know - my first major(ish) outing in the
PostgreSQL source, in particular I'm not use
Bruce Momjian writes:
> Lee Kindness wrote:
> > Right, so a reasonable angle for me to take is to go through the libpq
> > source looking for potential problem areas and use of "known bad"
> > functions. I can add autoconf checks for the replacement *_r()
> > functions, and use these in place
Lee Kindness wrote:
> Tom Lane writes:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > We have definatly had requests for improved thread-safeness for libpq
> > > and ecpg in the past, so whatever you can do would be a help. We say
> > > libpq is thread-safe, but specifically mention the n
Tom Lane writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > We have definatly had requests for improved thread-safeness for libpq
> > and ecpg in the past, so whatever you can do would be a help. We say
> > libpq is thread-safe, but specifically mention the non-threadsafe calls
> > in th
On Monday 06 January 2003 12:28, Lee Kindness wrote:
> Tom Lane writes:
> > Lee Kindness <[EMAIL PROTECTED]> writes:
> > > are protected, a sqlca for each thread), but of course it relies on
> > > libpq which needs work to share a connection between thrreads.
> > AFAIK, libpq is thread-safe al
Bruce Momjian <[EMAIL PROTECTED]> writes:
> We have definatly had requests for improved thread-safeness for libpq
> and ecpg in the past, so whatever you can do would be a help. We say
> libpq is thread-safe, but specifically mention the non-threadsafe calls
> in the libpq documentation, or at lea
We have definatly had requests for improved thread-safeness for libpq
and ecpg in the past, so whatever you can do would be a help. We say
libpq is thread-safe, but specifically mention the non-threadsafe calls
in the libpq documentation, or at least we should. We have been making
marginal threa
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > On a slightly related note to the other threads thread [sic] going
> > on... Over the Christmas/New Year break i've been looking into making
> > the PostgreSQL client libraries (in particular libpq and ecpg)
> > thread-safe - that
On Mon, Jan 06, 2003 at 11:58:17AM -0500, Tom Lane wrote:
>
> AFAIK, libpq is thread-safe already, it's just not thread-aware.
> What you'd presumably want is a wrapper layer that adds a mutex to
> prevent multiple threads from manipulating a PGconn at the same time.
> Couldn't this be done withou
Lee Kindness <[EMAIL PROTECTED]> writes:
> On a slightly related note to the other threads thread [sic] going
> on... Over the Christmas/New Year break i've been looking into making
> the PostgreSQL client libraries (in particular libpq and ecpg)
> thread-safe - that is they can safely be used by a
On a slightly related note to the other threads thread [sic] going
on... Over the Christmas/New Year break i've been looking into making
the PostgreSQL client libraries (in particular libpq and ecpg)
thread-safe - that is they can safely be used by a program which
itself is using mutliple threads.
12 matches
Mail list logo
