Re: Libpq driver: thread problem

I remember, that psqlodbc depends on ANSI C locale features.
ANSI C locale settings are not thread safe.

setlocale() functions are not thread safe in Windows and not in Linux:

convert.c: saved_locale =
strdup(setlocale(LC_ALL, NULL));
convert.c: setlocale(LC_ALL, "C");
convert.c: setlocale(LC_ALL, saved_locale);
convert.c: saved_locale =
strdup(setlocale(LC_ALL, NULL));
convert.c: setlocale(LC_ALL, "C");
convert.c: setlocale(LC_ALL, saved_locale);

They should be replaced with thread safe alternatives, when proven
thread safety
is required. Of course, this might work, if there is only a single
connection
and a single statement with many threads and no other application feature
depends on the global locale setting.

I think, that UTF-8 could be used internally under both Linux and Windows.
It would simplify the psqlodbc driver. Maybe SQL_ASCII would be the
exception.
Under Linux, there is iconv() function API, that can be used for the needed
thread safe conversion object.

Under Windows, the setlocale() function is thread local, if the
following code
is called:

_configthreadlocale(_ENABLE_PER_THREAD_LOCALE);

Is psqlodbc thread safe in Windows, if that is defined within main()
function?

There is an example about thread local locales near the bottom of page
http://msdn2.microsoft.com/library/x99tb11d(en-us,vs.80).aspx

I don't know any other thread safe locale API within Windows.

Could we use libicu under Linux and Windows? Is it thread safe?
Could we hide the locale details within libpq and just use it's
thread safe features?

Marko Ristola

Bruce Momjian wrote:

>Dave Page wrote:
>
>
>>>The main issue with the flag, as I remember, is to allow multiple
>>>threads to open libpq connections. If you don't do that, you
>>>don't need
>>>the flag.
>>>
>>>
>>In which case it definitely needs fixing. Which may be a non-trivial
>>task as pthreads on Windows is not currently used by PostgreSQL, and
>>didn't want to play last time I looked at it :-( However...
>>
>>I did look at this very briefly before speaking to Magnus. The first
>>problem I ran into was that configure was insisting that posix signals
>>were needed to enable thread safety. Before I spend lots of time looking
>>at the code do you know if it is safe for me to assume our signal
>>emaulation will do that job in all the right places? If so, I guess it's
>>just a case of fixing the pthread detection and linker flags.
>>
>>
>
>Ewe. I bet we added that test program _after_ we got threads working on
>Win32. That program, and the flags detection configure checks have made
>threads configuration almost fool-proof, so I don't think we should
>change any of that.
>
>As far as the Win32 API, I am unsure. Let me see if I can hack up
>thread_test.c to use libpq/pthread-win32.c to see if I can get that
>working.
>
>
>