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
usinglibecpg_r > > and B, using libecpg, then program linking against both of them is going to > > have tough time
livingwith 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.
Itwould 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
itshould be improved. Not worked around > > with two libraries.> > I thought glibc was the one to introduce libc_r in
thefirst place ---> are they making libc thread-safe now?> > What OS's are still using libc_r for threaded-ness? I
neverliked that> approach myself, and I resist adding it to our setup unless it is> required.> > One problem now is
thatwe don't have a way to create a separate libpq_r> for operating systems that use libc_r. We just create libpq and
itis> thread-safe.> > As for the configure flag, we still need it because we don't know the> flags required by all our
supportedOS's.
