Re: - Mailing list pgsql-hackers

Peter Eisentraut wrote:
> I've been thinking some about how exactly to provide the new option of
> thread-safe clients (libpq, ecpg).  Let me state the following goals:
> 
> a. Thread-safeness, where it makes a difference, is generally thought to
> be a performance hit, so the user needs to have a choice to use
> thread-safe libraries or not.

OK.

> b. The user needs to be able to make the choice at the time he builds his
> application, *not* at the time the PostgreSQL distribution is built or
> installed.

Agreed.

> Clearly, a thread-safe ecpg library is always going to be significantly
> different from the "normal" one, with all the mutex things that get pulled
> in, so it seems reasonable to always offer a libecpg_r alongside the
> libecpg.

True.  And we have lots of platforms that we don't know how to enable
thread-safeness.

> The question is whether a libpq_r should be provided if libpq is
> thread-safe by default (no *_r functions, libc_r, or special flags).  I
> think yes.  It could be a symlink, so it doesn't really waste space. But
> it would convenience users: Those who want to be sure to always link
> against a thread-safe version can point to libpq_r and don't have to
> create complicated detection mechanisms. Those who know that their system
> is thread-safe by default can simply use libpq to follow that convention.
> And of course it creates consistency with libecpg_r and does not bother
> the user with complicated internal artifacts.

I think adding a libpq_r on a platform that doesn't use *_r libraries is
just too confusing.

> A final note on the name of the configure option, --with-threads. First,
> it does not control an external package but an internal feature, so it
> should be --enable-.  Secondly, it does not use threads, only enable
> thread-safeness.  So --enable-thread-safe might be a better name.  Or if
> you want to be more precise, --enable-thread-safe-client.  The latter is
> what MySQL uses, in case anyone cares about that.

Peter, you are good with these subtle distinctions.  How about
--enable-thread-safeness?

I have an idea.  Seems we have two issues, libpq and ecpg.

For ecpg, we need a command-line flag to specify if we want threading in
the application.

For libpq and libpecpg, we will just produce whatever therading library
should be created on that platform, meaning either just one library, or
one with _r and one without.

So we tell them, if you want the ability to do threaded libpq and ecpg,
use the --enable-thread-safeness configure flag.  If it succeeds, it
means we know how to do it for that operating system, and you get
threading capability.  If it fails, you don't have threading.

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