Skip site navigation (1) Skip section navigation (2)

Re: Libpq driver: thread problem

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"Marko Ristola" <Marko(dot)Ristola(at)kolumbus(dot)fi>
Cc: <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: Libpq driver: thread problem
Date: 2005-08-12 21:23:58
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E4AC99E6@ratbert.vale-housing.co.uk (view raw or flat)
Thread:
Lists: 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(at)postgresql(dot)org 
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Bruce Momjian
> Sent: 12 August 2005 22:12
> To: Marko Ristola
> Cc: pgsql-odbc(at)postgresql(dot)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(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
> 
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

Responses

pgsql-odbc by date

Next:From: Bruce MomjianDate: 2005-08-12 21:24:40
Subject: Re: Libpq driver: thread problem
Previous:From: Bruce MomjianDate: 2005-08-12 21:12:19
Subject: Re: Libpq driver: thread problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group