Will PQregisterThreadLock() be documented?

Volkan YAZICI wrote:

Will PQregisterThreadLock() - which is defined globally in
src/interfaces/libpq/fe-connect.c - be documented?

Yes, it should be documented.

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Volkan YAZICI wrote:

Will PQregisterThreadLock() - which is defined globally in
src/interfaces/libpq/fe-connect.c - be documented?

Yes, it should be documented.

Really? Do we intend applications to call it?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Volkan YAZICI wrote:

Will PQregisterThreadLock() - which is defined globally in
src/interfaces/libpq/fe-connect.c - be documented?

Yes, it should be documented.

Really? Do we intend applications to call it?

Uh, well, we never call it ourselves, so if we don't expect other
applications to call it, why is it there?

Our code has:

/*
* Used to set callback that prevents concurrent access to
* non-thread safe functions that libpq needs.
* The default implementation uses a libpq internal mutex.
* Only required for multithreaded apps that use kerberos
* both within their app and for postgresql connections.
*/
typedef void (*pgthreadlock_t) (int acquire);

extern pgthreadlock_t PQregisterThreadLock(pgthreadlock_t newhandler);

We need to research why it was added.

-- 
  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

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Really? Do we intend applications to call it?

Uh, well, we never call it ourselves, so if we don't expect other
applications to call it, why is it there?

If it's intended for apps to call, how was the patch initially accepted
with no documentation?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <pgman@candle.pha.pa.us> writes:

Tom Lane wrote:

Really? Do we intend applications to call it?

Uh, well, we never call it ourselves, so if we don't expect other
applications to call it, why is it there?

If it's intended for apps to call, how was the patch initially accepted
with no documentation?

Not sure. That's why its history needs to be researched.

-- 
  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

Revision 1.269: Wed Mar 24 03:44:59 2004 UTC by momjian
Branches: MAIN
] Add thread locking to SSL and Kerberos connections.
]
] I have removed the docs mentioning that SSL and Kerberos are not
] thread-safe.
]
] Manfred Spraul

Diff to previous 1.268:
http://developer.postgresql.org/cvsweb.cgi/pgsql/src/interfaces/libpq/fe-connect.c.diff?r1=1.268;r2=1.269

FYI

Volkan YAZICI <volkan.yazici@gmail.com> writes:

Revision 1.269: Wed Mar 24 03:44:59 2004 UTC by momjian
Branches: MAIN
] Add thread locking to SSL and Kerberos connections.
]
] I have removed the docs mentioning that SSL and Kerberos are not
] thread-safe.
]
] Manfred Spraul

I note that PQinitSSL is likewise documentation-free.

Also, neither one of these two routines is listed in exports.txt,
meaning that Windows users are physically unable to call them
even if they knew they existed :-(

regards, tom lane

Tom Lane wrote:

Volkan YAZICI <volkan.yazici@gmail.com> writes:

Revision 1.269: Wed Mar 24 03:44:59 2004 UTC by momjian
Branches: MAIN
] Add thread locking to SSL and Kerberos connections.
]
] I have removed the docs mentioning that SSL and Kerberos are not
] thread-safe.
]
] Manfred Spraul

I note that PQinitSSL is likewise documentation-free.

Also, neither one of these two routines is listed in exports.txt,
meaning that Windows users are physically unable to call them
even if they knew they existed :-(

I have applied the following patch to document PQinitSSL() and
PQregisterThreadLock().

I also remove the crypt() mention in the libpq threading section and
added a single sentence in the client-auth manual page under crypt().
Crypt authentication is so old now that a separate paragraph about it
seemed unwise.

I also added a comment about our use of locking around pqGetpwuid().

-- 
  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