--On Friday, July 25, 2003 18:20:10 -0400 Greg Stark <[EMAIL PROTECTED]>
wrote:
Peter Eisentraut <[EMAIL PROTECTED]> writes:
Bruce Momjian writes:
> I still think it is confusing to create a libpq_r on platforms that
> have no _r libraries. I am on BSD/OS and I can find only _r library
> on
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>
> > I still think it is confusing to create a libpq_r on platforms that have
> > no _r libraries. I am on BSD/OS and I can find only _r library on my
> > entire system,
>
> The criterion is not whether the platform has _r li
Peter Eisentraut wrote:
> Bruce Momjian writes:
> 1. need to link in special libc_r (FreeBSD)
> 2. need to use magic flags for compiler and/or linker (FreeBSD, UnixWare)
> 3. need to compile with special preprocessor symbols (UnixWare, AIX)
> 4. need to use different compiler altogether (AIX)
>
>
--On Friday, July 25, 2003 11:51:50 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Larry Rosenman writes:
The -D_REENTRANT causes NO pain, and makes it possible to have ONE
library for UnixWare.
Didn't you just say that -D_REENTRANT changes the definition of errno on
your system? Surely it
Larry Rosenman writes:
> The -D_REENTRANT causes NO pain, and makes it possible to have ONE library
> for UnixWare.
Didn't you just say that -D_REENTRANT changes the definition of errno on
your system? Surely it would not be a good idea to link a libpq that uses
variant 1 with a program that use
--On Friday, July 25, 2003 11:23:05 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Bruce Momjian writes:
I still think it is confusing to create a libpq_r on platforms that have
no _r libraries. I am on BSD/OS and I can find only _r library on my
entire system,
The criterion is not whether
Bruce Momjian writes:
> I still think it is confusing to create a libpq_r on platforms that have
> no _r libraries. I am on BSD/OS and I can find only _r library on my
> entire system,
The criterion is not whether the platform has _r libraries, it's whether
special actions are required in order
--On Thursday, July 24, 2003 16:30:14 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Peter Eisentraut wrote:
Larry Rosenman writes:
> I beg to differ. Explicitly, on UnixWare, the header,
> reproduced below, under fair use, show an EXPLICIT difference in what
> happens with _REENTRANT:
Hmm,
Peter Eisentraut wrote:
> Larry Rosenman writes:
>
> > I beg to differ. Explicitly, on UnixWare, the header,
> > reproduced below, under fair use, show an EXPLICIT difference in what
> > happens with _REENTRANT:
>
> Hmm, I was too optimistic. I guess we'll just have to handcraft a
> different
> Better remove transactions then, yeah? Performace hit! Profile it and
> see how minor (or likely non-existent) it is...
You can do that. Turn fsync to off and you remove a large majority of
the transaction hit, but I understand what you're saying.
signature.asc
Description: This is a digitall
Peter Eisentraut writes:
> Larry Rosenman writes:
> > I beg to differ. Explicitly, on UnixWare, the header,
> > reproduced below, under fair use, show an EXPLICIT difference in what
> > happens with _REENTRANT:
> Hmm, I was too optimistic. I guess we'll just have to handcraft a
> different
Larry Rosenman writes:
> I beg to differ. Explicitly, on UnixWare, the header,
> reproduced below, under fair use, show an EXPLICIT difference in what
> happens with _REENTRANT:
Hmm, I was too optimistic. I guess we'll just have to handcraft a
different solution for each platform. But clearly
Bruce Momjian writes:
> Peter Eisentraut wrote:
> > Bruce Momjian writes:
> > > THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
> > Those flags are bogus. You don't need any flags under Linux.
> Is that true for all versions of Linux? Don't we need the first one so
>
--On Thursday, July 24, 2003 17:21:17 +0200 Peter Eisentraut
<[EMAIL PROTECTED]> wrote:
Bruce Momjian writes:
Now I see what you are saying, that _REENTRANT just makes it reentrant,
_REENTRANT only makes additional functions visible in the header files, it
doesn't change any functions to behav
Peter Eisentraut wrote:
> Bruce Momjian writes:
>
> > Now I see what you are saying, that _REENTRANT just makes it reentrant,
>
> _REENTRANT only makes additional functions visible in the header files, it
> doesn't change any functions to behave differently. (This is not hard to
> imagine, becau
Bruce Momjian writes:
> Now I see what you are saying, that _REENTRANT just makes it reentrant,
_REENTRANT only makes additional functions visible in the header files, it
doesn't change any functions to behave differently. (This is not hard to
imagine, because the lack of reentrancy of most func
Bruce Momjian writes:
> However, notice the flags needed under Linux:
>
> THREAD_CFLAGS="-D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS"
>
> or are you saying libpq needs only the first one because libpq, itself,
> doesn't use threads --- interesting distinction, and perhaps a
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Now I see what you are saying, that _REENTRANT just makes it reentrant,
> and doesn't have a downside in terms of performance.
That's at best an unsupported assertion. Why would the platform bother
with supplying two copies of libc if they didn't think
Tom Lane writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Now I see what you are saying, that _REENTRANT just makes it reentrant,
> > and doesn't have a downside in terms of performance.
> That's at best an unsupported assertion. Why would the platform bother
> with supplying two copie
Lee Kindness wrote:
> Tom Lane writes:
> > Lee Kindness <[EMAIL PROTECTED]> writes:
> > > Bruce Momjian writes:
> > >>> My guess is that if the OS has separate threaded libs, we have to mimic
> > >>> that stuff.
> > > But there are NO thread primitives/calls in libpq
> > That's not the point
Tom Lane writes:
> If the OS supplies both libc and libc_r, it is unlikely to be a good
> idea to link a threaded libpq with libc, or a non-threaded libpq with
> libc_r.
What modern OS has libc_r? The majors (Linux, Soalris, HPUX, AIX)
certainly do not.
L.
---(end of b
Tom Lane writes:
> Lee Kindness <[EMAIL PROTECTED]> writes:
> > Bruce Momjian writes:
> >>> My guess is that if the OS has separate threaded libs, we have to mimic
> >>> that stuff.
> > But there are NO thread primitives/calls in libpq
> That's not the point. The point is stuff that isn't n
Lee Kindness <[EMAIL PROTECTED]> writes:
> Bruce Momjian writes:
>>> My guess is that if the OS has separate threaded libs, we have to mimic
>>> that stuff.
> But there are NO thread primitives/calls in libpq
That's not the point. The point is stuff that isn't necessarily visible
in the source
Lee Kindness writes:
> Guys, take a look at what was done in libpq to make it
> thread-safe... No locks! No overheaded - just using "proper" reentrant
> functions...
There is a difference between being reentrant and being thread-safe.
Making libpq reentrant is relatively easy if you use the right
--On Thursday, July 24, 2003 08:52:37 -0400 Bruce Momjian
<[EMAIL PROTECTED]> wrote:
Lee Kindness wrote:
Guys, take a look at what was done in libpq to make it
thread-safe... No locks! No overheaded - just using "proper" reentrant
functions...
If we have libpq_r then we're making a complete has
Bruce Momjian writes:
> Lee Kindness wrote:
> > Guys, take a look at what was done in libpq to make it
> > thread-safe... No locks! No overheaded - just using "proper" reentrant
> > functions...
> > If we have libpq_r then we're making a complete hash of it all - being
> > reentrant is good,
Lee Kindness wrote:
> Guys, take a look at what was done in libpq to make it
> thread-safe... No locks! No overheaded - just using "proper" reentrant
> functions...
>
> If we have libpq_r then we're making a complete hash of it all - being
> reentrant is good, even if you're not using threads!
>
Guys, take a look at what was done in libpq to make it
thread-safe... No locks! No overheaded - just using "proper" reentrant
functions...
If we have libpq_r then we're making a complete hash of it all - being
reentrant is good, even if you're not using threads!
Now, ecpg is another issue...
L.
28 matches
Mail list logo
