Re: PostgreSQL libraries - PThread Support, but not use...
От | Bruce Momjian |
---|---|
Тема | Re: PostgreSQL libraries - PThread Support, but not use... |
Дата | |
Msg-id | 200301071518.h07FIOY06041@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: PostgreSQL libraries - PThread Support, but not use... (Lee Kindness <lkindness@csl.co.uk>) |
Ответы |
Re: PostgreSQL libraries - PThread Support, but not use...
|
Список | pgsql-hackers |
Lee Kindness wrote: > Tom Lane writes: > > Bruce Momjian <pgman@candle.pha.pa.us> 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 least we should. > > We do: > > http://www.ca.postgresql.org/users-lounge/docs/7.3/postgres/libpq-threading.html > > But Lee's point about depending on possibly-unsafe libc routines is a > > good one. I don't think anyone's gone through the code with an eye to > > that. > > 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 of the traditional ones where > available. I am a little confused by the *_r functions. Are they for all functions? BSD/OS doesn't have them, but all our libc functions are threadsafe except for things like strtok, where they recommend strsep, and gethostbyname, where they would suggest getaddrinfo, I guess. > If any function is found to be not thread-safe and cannot be made so > using standard library calls then it needs to be documented as such > both in the source and the aforementioned documentation. Ideally we will find we can get them all fixed in some way. > This approach avoids any thread library dependencies and documents the > current state of play WRT thread safety (i.e it's a good, and needed, > basis for any later work). Yes, good idea. > ECPG is a separate issue, and best handled as such (it will need > thread calls). I'll post a patch for it at a later date so the changes > are available to anyone who wants to play with ECPG and threads. Yes, needs to be done too. Someone was complaining about ecpg not being thread safe several months ago. I don't remember the details. -- 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 по дате отправления: