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.
Bruce Momjian writes:
> Shridhar Daithankar wrote:
> > I repeat what I have said earlier. If there are two libraries A using libecpg_r
> > and B, using libecpg, then program linking against both of them is going to
> > have tough time living with symbol conflicts.
> >
> > I suppose problem will be reproducible even under freeBSD if you try to create
> > a postgresql function in C which uses threads. Link the library against libc_r
> > and link postgresql against libc. It would run into problems.
> >
> > I am just stating my experiences.I might have missed solution to this problem.
> >
> > But overall I like GNU libc approach of everything thread safe by default. If
> > thread performance is an issue, then it should be improved. Not worked around
> > with two libraries.
>
> I thought glibc was the one to introduce libc_r in the first place ---
> are they making libc thread-safe now?
>
> What OS's are still using libc_r for threaded-ness? I never liked that
> approach myself, and I resist adding it to our setup unless it is
> required.
>
> One problem now is that we don't have a way to create a separate libpq_r
> for operating systems that use libc_r. We just create libpq and it is
> thread-safe.
>
> As for the configure flag, we still need it because we don't know the
> flags required by all our supported OS's.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
