Re: Libpq driver: thread problem

This has been saved for the 8.2 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

---------------------------------------------------------------------------

Marko Ristola wrote:
>
> 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.
> >
> >
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/docs/faq
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073