Re: [RFR] man://glibc-glibcA/fr.po
Merci d'avance pour vos relectures.
Relecture dans le fichier joint.
--
Stephane.
--- glibcA.po 2006-08-11 02:51:59.000000000 +0200
+++ glibcA.stephane.po 2006-08-11 04:32:33.000000000 +0200
@@ -114,7 +114,7 @@
"parent| and |child| handlers are called in FIFO order (first added, first "
"called)."
msgstr ""
-"B<pthread_atfork> peut être appelée plusieurs fois pour enregistrer "
+"B<pthread_atfork> peut être appelé plusieurs fois pour enregistrer "
"plusieurs ensembles de gestionnaires. Lors de l'appel à B<fork>(2), les "
"gestionnaires I<prepare> sont appelés dans l'ordre LIFO (dernier ajouté avec "
"B<pthread_affork>, premier appelé avant B<fork>(2)), alors que les "
@@ -134,7 +134,7 @@
msgstr ""
"Pour comprendre l'objectif de B<pthread_atfork>(), rappelons que B<fork>(2) "
"copie toute l'image mémoire du processus, y compris ses mutexes dans leur "
-"état de bloquage courant, mais seulement le thread appelant\\ : les autres "
+"état de blocage courant, mais seulement le thread appelant\\ : les autres "
"threads ne s'exécutent pas dans le processus fils. Les mutexes ne sont pas "
"utilisables après le B<fork>() et doivent être initialisés avec "
"B<pthread_mutex_init>() dans le processus fils. C'est une limitation de "
@@ -327,7 +327,7 @@
msgstr ""
"B<pthread_attr_init>() initialise la structure d'attributs de thread I<attr> "
"et la remplit avec les valeurs par défaut pour tous les attributs (Les "
-"valeurs par défauts de chaque attribut sont données plus bas)."
+"valeurs par défaut de chaque attribut sont données plus bas)."
# type: Plain text
#: C/man3/pthread_attr_init.3:60
@@ -348,7 +348,7 @@
"reused until it is reinitialized. !pthread_attr_destroy! does nothing in the "
"LinuxThreads implementation."
msgstr ""
-"B<pthread_attr_destroy>() détruit une structure d'attribut de thread, qui ne "
+"B<pthread_attr_destroy>() détruit une structure d'attribut de thread qui ne "
"doit plus jamais être réutilisée jusqu'à ce qu'elle soit réinitialisée. "
"B<pthread_attr_destroy>() ne fait rien dans l'implémentation LinuxThreads."
@@ -443,7 +443,7 @@
msgstr ""
"Change la politique d'ordonnancement du thread pour l'une parmi "
"B<SCHED_OTHER> (processus normal, non temps réel), B<SCHED_RR> (temps réel, "
-"«\\ round-robin\\ ») ou B<SCHED_FIFO> (temps réel, «\\ fifo\\ »). Voyez "
+"«\\ round-robin\\ ») ou B<SCHED_FIFO> (temps réel, «\\ fifo\\ »). Consultez "
"B<sched_setpolicy>(2) pour plus d'informations sur les politiques "
"d'ordonnancement."
@@ -528,7 +528,7 @@
msgstr ""
"Indique si la politique et les paramètres d'ordonnancement du nouveau thread "
"sont déterminés par les valeurs des attributs I<schedpolicy> et "
-"I<schedparam> (valeur B<PTHREAD_EXPLICIT_SCHED>) ou sont héritées du thread "
+"I<schedparam> (valeur B<PTHREAD_EXPLICIT_SCHED>) ou sont hérités du thread "
"parent (valeur B<PTHREAD_INHERIT_SCHED>)."
# type: Plain text
@@ -780,13 +780,13 @@
"specific data are called, and finally the thread stops executing with the "
"return value !PTHREAD_CANCELED!. See !pthread_exit!(3) for more information."
msgstr ""
-"Quand un thread réalise finalement la requête d'annulation, il se comporte "
+"Quand un thread réalise finalement une requête d'annulation, il se comporte "
"comme si la fonction B<pthread_exit(PTHREAD_CANCELED)> avait été appelée à "
"cet endroit\\ : tous les gestionnaires de nettoyage sont exécutés dans "
"l'ordre inverse de leur enregistrement. Puis les fonctions de destruction "
"des données spécifiques au thread sont appelées. Enfin, le thread interrompt "
"définitivement son exécution en retournant la valeur B<PTHREAD_CANCELED>. "
-"Voyez B<pthread_exit>(3) pour plus d'informations."
+"Consultez B<pthread_exit>(3) pour plus d'informations."
# type: Plain text
#: C/man3/pthread_cancel.3:38
@@ -832,7 +832,7 @@
"pthread_setcanceltype!."
msgstr ""
"B<pthread_setcanceltype>() modifie le mode de réponse de la requête "
-"d'annulation du thread appelant\\ : asynchrone (immédiate) ou retardée. Le "
+"d'annulation du thread appelant\\ : asynchrone (immédiat) ou retardé. Le "
"paramètre I<type> est le nouveau mode d'annulation\\ : soit "
"B<PTHREAD_CANCEL_ASYNCHRONOUS> pour annuler le thread appelant dès que "
"possible après la réception d'une requête d'annulation, soit "
@@ -947,7 +947,7 @@
msgid ""
"no thread could be found corresponding to that specified by the |thread| ID."
msgstr ""
-"Aucun thread correspondant au descripteur I<thread> n'a pu êtres trouvé."
+"Aucun thread correspondant au descripteur I<thread> n'a pu être trouvé."
# type: Plain text
#: C/man3/pthread_cancel.3:106
@@ -1004,7 +1004,7 @@
"et les fonctions des bibliothèques qui invoquent ces appels système (par "
"exemple, B<fprintf>(3)) sont des points d'annulation. LinuxThreads n'est pas "
"encore assez intégré à la bibliothèque standard C pour implémenter cela\\ ; "
-"et donc, aucune fonction de la glibc n'est un point d'annulation."
+"C'est pourquoi aucune fonction de la glibc n'est un point d'annulation."
# type: Plain text
#: C/man3/pthread_cancel.3:144
@@ -1017,7 +1017,7 @@
msgstr ""
"Pour les appels système, il existe un moyen détourné d'y parvenir. Les "
"requêtes d'annulation sont transmises au thread ciblé en lui envoyant un "
-"signal. Ce dernier va interrompre tous les appels système bloquant, ils "
+"signal. Ce dernier va interrompre tous les appels système bloquant qui "
"renvoient alors immédiatement l'erreur B<EINTR>. Ainsi, pour vérifier qu'un "
"thread n'a pas été annulé au cours de l'appel système B<read>(), par "
"exemple, on peut utiliser la méthode suivante\\ :"
@@ -1098,7 +1098,7 @@
msgstr ""
"Le rôle d'un gestionnaire de nettoyage est de libérer les ressources "
"acquises par un thread lorsque son exécution s'achève. En particulier, si un "
-"thread se termine, ou est annulé alors qu'il verrouille un mutex, ce dernier "
+"thread se termine ou est annulé alors qu'il verrouille un mutex, ce dernier "
"restera verrouillé pour toujours, empêchant d'autres threads de s'exécuter "
"normalement. La meilleure manière d'empêcher cela est d'installer un "
"gestionnaire de nettoyage dont la fonction sera de déverrouiller le mutex. "
@@ -1193,7 +1193,7 @@
"occur in matching pairs, at the same level of block nesting."
msgstr ""
"B<pthread_cleanup_push_defer_np>() et B<pthread_cleanup_pop_restore_np>() "
-"doivent être exécutées en paire, dans le même bloc, au même niveau et ne "
+"doivent être exécutées par paire, dans le même bloc, au même niveau et ne "
"peuvent pas être entrelacées avec une autre paire."
# type: Plain text
@@ -1318,7 +1318,7 @@
"If the code above must also work in asynchronous cancellation mode, then it "
"must switch to deferred mode for locking and unlocking the mutex:"
msgstr ""
-"Afin que ce code fonctionne aussi en mode d'annulation asynchrone, il doit "
+"Afin que le code précédent fonctionne aussi en mode d'annulation asynchrone, il doit "
"passer en mode d'annulation retardée pour verrouiller et déverrouiller le "
"mutex\\ :"
@@ -1463,7 +1463,7 @@
"for conditions, hence the |cond_attr| parameter is actually ignored."
msgstr ""
"B<pthread_cond_init>() initialise la variable condition I<cond>, en "
-"utilisant les attributs de condition spécifiés par I<cond_attr>, ou les "
+"utilisant les attributs de condition spécifiés par I<cond_attr> ou les "
"attributs par défaut si I<cond_attr> vaut B<NULL>. L'implémentation "
"LinuxThreads ne supporte aucun attribut de condition, aussi le paramètre "
"I<cond_attr> est pour l'instant ignoré."
@@ -1515,7 +1515,7 @@
"B<pthread_cond_wait>() déverrouille atomiquement le I<mutex> (comme "
"B<pthread_unlock_mutex>()) et attend que la variable condition I<cond> soit "
"signalée. L'exécution du thread est suspendue et ne consomme pas de temps "
-"CPU jusqu'à ce que la variable condition soit signalée. Le I<mutex> doit "
+"processeur jusqu'à ce que la variable condition soit signalée. Le I<mutex> doit "
"être verrouillé par le thread appelant à l'entrée de B<pthread_cond_wait>(). "
"Avant de rendre la main au thread appelant, B<pthread_cond_wait>() re-"
"verrouille I<mutex> (comme B<pthread_lock_mutex>())."
Reply to: