What exactly is our policy towards global variables in libraries? I take is
these variables are harmless in multi tasking operation as each process has
its seperate data space. But they may do harm in multi threading. But then
libpq are is not suitable for multi threading, is it?

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!

Tue, 7 Mar 2000 15:57:45 +0100
Michael Meskes <meskes@postgresql.org>
library policy question
Michael Meskes <meskes@postgreSQL.org> writes:
> What exactly is our policy towards global variables in libraries?

Avoid them.

> But then libpq are is not suitable for multi threading, is it?

AFAIK, libpq's only use of non-constant globals is the ill-designed
PQconninfoOption array.  I'd get rid of that if it didn't mean breaking
the library API.  But as things stand, you can't safely use concurrent
calls to PQconnectdb or PQconndefaults.  Everything else should be OK,
unless someone has broken it recently.

(idly examines code...)

Hmm, we do have a bit of a problem here.  While PQconnectdb can be
replaced by PQsetdb to avoid the concurrency issue, there is no
thread-safe equivalent for the new routines
PQconnectStart/PQconnectPoll.  That may not matter much, because
probably you would only need those in a single-threaded environment,
but it's still kinda ugly.  In any case it'd be a lot nicer to be
able to say "libpq is thread safe" rather than "almost thread safe".

At one point we had discussed going ahead and breaking compatibility
in order to get rid of the static PQconninfoOption array.  It wouldn't
be a big change in the API: we'd only need to make PQconndefaults return
a malloc'd array instead of a static.  That probably wouldn't really
break any existing code, just create a small memory leak in applications
that didn't know to free the result when they were done with it.  My bet
is that very few apps use PQconndefaults anyway.

7.0 would be a good time to do that if we were gonna do it.  Comments?

			regards, tom lane

Tue, 07 Mar 2000 11:34:04 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] library policy question 
> 7.0 would be a good time to do that if we were gonna do it.  Comments?

Yup.

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Tue, 07 Mar 2000 16:57:45 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] library policy question
Tom Lane wrote:
> but it's still kinda ugly.  In any case it'd be a lot nicer to be
> able to say "libpq is thread safe" rather than "almost thread safe".
 
> 7.0 would be a good time to do that if we were gonna do it.  Comments?

If time is available to do that, I agree that now is an great time to do
so. As a user of a multithreaded web front end to PostgreSQL
(AOLserver), I personally am affected by the result.  The AOLserver
PostgreSQL driver avoids the PQconnectdb() issue by using
PQsetdbLogin().

HOWEVER, it was a hunt to find that information -- it would have been
nice for the docs to say 'libpq {is|is not} threadsafe' -- even 'libpq
is threadsafe if and only if the following API calls are used:' would be
nice.
In fact, even if libpq is not touched, a documentation note to libpq's
threadsafeness would be nice.

--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Tue, 07 Mar 2000 11:57:50 -0500
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] library policy question
On Tue, Mar 07, 2000 at 11:34:04AM -0500, Tom Lane wrote:
> > What exactly is our policy towards global variables in libraries?
> 
> Avoid them.

And what shall I do with sqlca? Make every program define it in its own space?

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!

Tue, 7 Mar 2000 20:25:10 +0100
Michael Meskes <meskes@postgreSQL.org>
Re: [HACKERS] library policy question
On Tue, 7 Mar 2000, Thomas Lockhart wrote:

> > 7.0 would be a good time to do that if we were gonna do it.  Comments?
> 
> Yup.

Ditto ... 



Tue, 7 Mar 2000 19:06:24 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] library policy question
The Hermit Hacker <scrappy@hub.org> writes:
> On Tue, 7 Mar 2000, Thomas Lockhart wrote:
>>>> 7.0 would be a good time to do that if we were gonna do it.  Comments?
>> 
>> Yup.

> Ditto ... 

OK, I'll take a look at doing it later this week.

			regards, tom lane

Tue, 07 Mar 2000 20:28:02 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] library policy question 
> Hmm, we do have a bit of a problem here.  While PQconnectdb can be
> replaced by PQsetdb to avoid the concurrency issue, there is no
> thread-safe equivalent for the new routines
> PQconnectStart/PQconnectPoll.  That may not matter much, because
> probably you would only need those in a single-threaded environment,
> but it's still kinda ugly.  In any case it'd be a lot nicer to be
> able to say "libpq is thread safe" rather than "almost thread safe".
> 
> At one point we had discussed going ahead and breaking compatibility
> in order to get rid of the static PQconninfoOption array.  It wouldn't
> be a big change in the API: we'd only need to make PQconndefaults return
> a malloc'd array instead of a static.  That probably wouldn't really
> break any existing code, just create a small memory leak in applications
> that didn't know to free the result when they were done with it.  My bet
> is that very few apps use PQconndefaults anyway.
> 
> 7.0 would be a good time to do that if we were gonna do it.  Comments?
> 

Seems like a good time to do it.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 7 Mar 2000 20:35:01 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] library policy question
> And what shall I do with sqlca? Make every program define it in its own 
> space?

My vague recollection is that embedded SQL doesn't multithread very
well for exactly this reason. You may be stuck with a global variable
for that case...

                      - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Wed, 08 Mar 2000 14:06:35 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] library policy question
On Tue, Mar 07, 2000 at 11:34:04AM -0500, Tom Lane wrote:
> > What exactly is our policy towards global variables in libraries?
> 
> Avoid them.

Maybe I've got a brain lock for the moment but what do I do to the list of
connections I have to handle? Since it is used in several functions I cannot
see how to program this without a global variable albeit a static one. What
I need is a mapping of the SQL conenction name to the PGconn structure.

I also wonder if multiple threads should be allowed access to the same
structure, i.e. if one thread opens a new connection should the other one be
allowed to access this too?

BTW libpgeasy does not seem to be able to be used in multi-threading
environments either. Is this library still supported?

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!

Wed, 8 Mar 2000 16:30:10 +0100
Michael Meskes <meskes@postgreSQL.org>
Re: [HACKERS] library policy question
On Wed, Mar 08, 2000 at 02:06:35PM +0000, Thomas Lockhart wrote:
> My vague recollection is that embedded SQL doesn't multithread very
> well for exactly this reason. You may be stuck with a global variable
> for that case...

I was afraid you'd say that. So I can use lots of global vars since libecpg
does not multithread anyway. :-)

Michael
-- 
Michael Meskes                         | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz    | Go Rhein Fire!
Tel.: (+49) 2431/72651                 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De           | Use PostgreSQL!

Wed, 8 Mar 2000 17:40:34 +0100
Michael Meskes <meskes@postgreSQL.org>
Re: [HACKERS] library policy question
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
>> And what shall I do with sqlca? Make every program define it in its own 
>> space?

> My vague recollection is that embedded SQL doesn't multithread very
> well for exactly this reason. You may be stuck with a global variable
> for that case...

Aside from the unthreadable API, ecpg has another potential threading
problem: it depends on a lexer and parser that might or might not be
thread-safe, depending on what they were generated with.

I'd advise just labeling ecpg "not threadable" :-(.  Not much point in
breaking existing apps by changing the API, when you still won't be able
to guarantee thread safeness...

			regards, tom lane

Wed, 08 Mar 2000 14:49:32 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] library policy question 