libpq est réentrante et compatible avec les threads par
défaut. Vous pourriez avoir besoin d'utiliser des options de
compilation supplémentaires en ligne lorsque vous compilez le code de votre
application. Référez-vous à la documentation de votre système pour savoir
comment construire des applications avec threads ou recherchez
PTHREAD_CFLAGS
et PTHREAD_LIBS
dans
src/Makefile.global
. Cette fonction permet d'interroger
le statut de compatibilité de libpq avec les
threads :
PQisthreadsafe
#Renvoie le statut de compatibilité avec les threads pour libpq library.
int PQisthreadsafe();
Renvoie 1 si libpq supporte les threads, 0 dans le cas contraire.
Une restriction : il ne doit pas y avoir deux threads
manipulant le même objet PGconn
à la fois. En particulier, vous
ne pouvez pas lancer des commandes concurrentes depuis des threads
différents à travers le même objet de connexion (si vous avez besoin de lancer des
commandes concurrentes, utilisez plusieurs connexions).
Les objets PGresult
sont normalement en lecture seule
après leur création et, du coup, peuvent être passés librement entre les
threads. Néanmoins, si vous utilisez une des fonctions
décrites dans Section 34.12 ou Section 34.14
qui modifient PGresult
, il est de votre responsabilité
d'éviter des opérations concurrentes sur le même
PGresult
.
Les fonctions obsolètes
PQrequestCancel
et
PQoidStatus
ne gèrent pas les threads et ne devraient pas être utilisées dans des programmes multithreads. PQrequestCancel
peut être
remplacé par PQcancel
.
PQoidStatus
peut être remplacé par
PQoidValue
.
Si vous utilisez Kerberos avec votre application (en plus de
libpq), vous aurez besoin de verrouiller les appels
Kerberos car les fonctions Kerberos ne supportent pas les threads.
Voir la fonction PQregisterThreadLock
dans le code source de libpq sur comment
faire un verrouillage coopératif entre libpq et
votre application.