Re:
От | Bruce Momjian |
---|---|
Тема | Re: |
Дата | |
Msg-id | 200307231735.h6NHZP701646@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>) |
Ответы |
Re:
libpq_r |
Список | pgsql-hackers |
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. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: