Version imprimable
Bonjour,
Je développe actuellement une application multi-threadée et dans plusieurs des threads qui compose mon programme je fais appel à des fonctions susceptibles de modifier la variable globale errno (comme par exemple recv). J'aurais aimé savoir si un mécanisme a été prévu pour empêcher les accès concurrents à errno ou bien si cette tâche est la charge du programmeur (en l'occurence moi).
D'avance merci.
Il y a un errno par processus. Il est donc effectivement commun à tous les threads d'un même processus. Il n'y a aucun mécanisme intégré pour protéger errno. Comme ce sont les fonctions de la bibliothèque qui le modifient, tout peut arriver.Citation:
Envoyé par Montag
On peut dire que errno n'est pas utilisable du tout en multithread, à moins de placer les appels de fonctions dans des zones critiques (non interruptibles).
Il semblerait néanmoins que dans la pratique, l'usage, notamment des pthreads se fasse avec une valeur protégée de errno.
Cela dépend de la plate-forme, car errno peut être une macro et non une simple variable globale.
Le runtime C de Microsoft accorde un errno par thread, ce qui rend errno thread-safe sous Windows.
Ailleurs, rien ne peut être dit : Le comportement de errno en multithread n'est pas standardisé, car le C standard n'a pas la notion de multithread.
Bon à savoir, mais piégeant si on ecrit du code portable...Citation:
Envoyé par Médinoc
En effet.
Les effets du multithread sur les fonctionnalités standard non-réentrantes devraient toujours être spécifiés dans la documentation de l'API de multithreading utilisée...
J'ignore si c'est effectivement spécifié ou non, mais ça fait de errno une source d'incompatibilité entre APIs de multithreading...
Je suis tombé sur ce thread :
http://lists.apple.com/archives/coco.../msg00353.html
Apparemment, la question est laissée sans réponse...Citation:
Envoyé par Montag
En fait il y a une réponse mais elle n'est pas très claire (en tout cas pour moi) :Citation:
Apparemment, la question est laissée sans réponse...
Citation:
On thursday, march 7, 2002, at 05:52 , christophe dore wrote:
Yes, in all good thread-safe environnement, errno should be thread-safe.
On Linux, (I dunoo for OSX) the #defined variable _REENTRANT helps the compiler to choose, for errno and other dual API, xhat must be actually used.
In my make files, I used to write things like
ifeq $(USE_THREADS) "YES"
CFLAGS += -D_REENTRANT -lpthread.
POSIX.1c demande que errno soit thread-safe:
mais dans un meme temps, les fonctions POSIX preferent retourner un code d'erreur que d'utiliser errno...Citation:
Some functions may provide the error number in a variable accessed through the symbol errno. The symbol errno is defined by including the header <errno.h>, as specified by the C Standard [...] For each thread of a process, the value of errno shall not be affected by function calls or assignments to errno by other threads.
Oui mais POSIX ne précise pas comment rendre errno thread-safe. La seule solution est-elle, comme Emmanuel l'a suggéré de protéger l'appel à des fonctions non-réentrantes avec des mutex ou des sémaphores ou bien y a t'il des solutions moins lourdes comme le suggère mon post précédentCitation:
Envoyé par DaZumba
Tu ne peux rendre errno thread-safe avec des sections critiques, puisque le programme utilisateur ne peut pas réserver ces sections.
Le plus simple est de faire des variables séparées pour chaque thread:
- Dans l'exemple de ton lien, errno utilise la fonction __error(), qui retourne un pointeur.
- Dans la CRT de Microsoft, c'est là même chose, sauf que j'ai en plus le code source de la fonction __error() : Elle retourne un pointeur vers une zone mémoire spécifique au thread en cours.