> >> It is not; the main reason why not is a brain-dead part of
> >> the API that exposes modifiable global variables.
>
> > Hmm. Really?
>
> PQconnectdb() is the function that's not thread-safe; if you had
> multiple threads invoking PQconnectdb() in parallel you would see a
> problem. PQconndefaults() is the function that creates an
> API problem,
> because it exposes the static variable that PQconnectdb()
> ought not have
> had in the first place.
Ok. Now I see it. I guess my code worked because I run PQconnectdb() at the
start of the program, and hand down the PGconn:s to the threads later. So
only one thread can call PQconnectdb().
> There might be some other problems too, but that's the main one I'm
> aware of. If we didn't mind breaking existing apps that use
> PQconndefaults(), it would be straightforward to fix...
Wouldn't it be possible to do something like this (ok, a little bit ugly,
but shouldn't break the clients):
Store the "active" PQconninfoOptions array inside the PGconn struct. That
way, the user should not require to change anything when doing PQconnectdb()
and the likes.
Rewrite the conninfo_xxx functions to take a (PQconninfoOptions *) as
parameter to work on, instead of working on the static array.
Keep the static array, rename it to PQconninfoDefaultOptions, make it
contain the *default* options *from the beginning*, and declare it as
"const". Then have PQconndefaults() return that array. Then the
PQconndefaults() works just like before, and does not break the old
programs.
Shouldn't this be possible to achieve without any changes in the API?
If you don't see anything obviously wrong with this, I can try to put
together a patch to do that. It'd be really nice to have a thread-safe
client lib :-)
> You might want some kind of reference-counting
> mechanism for PGresults though.
In this case, the PGresults are owned by the client connections, and are
only used by one client connection at a time, and they are freed when the
client connection ends. The PGconns are owned one each by the Worker Threads
in the pool, and are freed when the worker thread is stopped (which is when
the application is stopped). So no special reference-counting should be
needed.
//Magnus