RE: [HACKERS] Threads
От | Magnus Hagander |
---|---|
Тема | RE: [HACKERS] Threads |
Дата | |
Msg-id | 215896B6B5E1CF11BC5600805FFEA82101F70C0F@sirius.edu.sollentuna.se обсуждение исходный текст |
Ответы |
Re: [HACKERS] Threads
|
Список | pgsql-hackers |
> >> 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
В списке pgsql-hackers по дате отправления: