Re: Libpq driver: thread problem - Mailing list pgsql-odbc

Err, what's been saved? This is part of a discussion re psqlODBC -
there's no patches here yet, and any that do come of it will be for
psqlODBC, not the server.

Regards, Dave

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Bruce Momjian
> Sent: 12 August 2005 22:12
> To: Marko Ristola
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] 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@candle.pha.pa.us               |  (610) 359-1001
>   +  If your life is a hard drive,     |  13 Roberts Road
>   +  Christ can be your backup.        |  Newtown Square,
> Pennsylvania 19073
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>