Je ne comprends pas pourquoi l'implantation threads posix sous Linux
ne renvoie pas ESRCH.
n'étant pas ouvert à la discussion ou très peu
(http://sources.redhat.com/bugzilla/show_bug.cgi?id`)
S'il s'agit d'un bug, comment faire pour envoyer un signal à un
thread de façon _sûre_ ?
Je ne comprends pas pourquoi l'implantation threads posix sous Linux
ne renvoie pas ESRCH.
n'étant pas ouvert à la discussion ou très peu
(http://sources.redhat.com/bugzilla/show_bug.cgi?id`)
S'il s'agit d'un bug, comment faire pour envoyer un signal à un
thread de façon _sûre_ ?
Je ne comprends pas pourquoi l'implantation threads posix sous Linux
ne renvoie pas ESRCH.
n'étant pas ouvert à la discussion ou très peu
(http://sources.redhat.com/bugzilla/show_bug.cgi?id`)
S'il s'agit d'un bug, comment faire pour envoyer un signal à un
thread de façon _sûre_ ?
JKB wrote in message :Je ne comprends pas pourquoi l'implantation threads posix sous Linux
ne renvoie pas ESRCH.
Ce que tu cites de la norme dit que la fonction _peut_ retourner cette
erreur, mais pas qu'elle _doit_ le faire. C'est assez systématique dans la
rédaction de ces normes, il faut en prendre l'habitude pour ne pas se
tromper.n'étant pas ouvert à la discussion ou très peu
(http://sources.redhat.com/bugzilla/show_bug.cgi?id`)
Ulrich Drepper est imbuvable comme à son habitude, mais il n'a pas tort dans
ce qu'il dit dans le commentaire 4 : envoyer un signal à un thread qui
n'existe pas n'est pas une erreur de circonstance (comme un filesystem plein
ou un réseau inaccessible) mais une erreur dans la structure du programme :
si le programmeur a compris qu'il ne devait pas le faire, une fois son
programme débuggé, ça n'arrive plus.
Et si ça n'arrive pas dans un programme débuggé, alors on peut se dispenser
des tests dans la bibliothèque, ça fait que ça s'exécute plus vite. C'est
peu important pour une bibliothèque comme Gtk+ où de toutes façons il va y
avoir énormément de temps passé en communication avec le serveur X11 ou sur
le rendu de glyphes vectoriels, mais pour la libc, en particulier les
communications inter-threads, on s'attend à ce que ça aille le plus vite
possible.
Si tu veux débugger, tu lies tes programmes à une version de la glibc
compilée pour le débuggage. Il y a ce qu'il faut dans pthread_kill pour
détecter certaines des erreurs (et retourner ESRCH).
Note que, sous GNU, un thread_t est un pointeur, et pthread_kill le
déréférence. Donc autant tester un pointeur nul pour géré le cas du bug que
tu cites est facile, autant tester le cas d'un pointeur déjà libéré est
essentiellement impossible.
S'il s'agit d'un bug, comment faire pour envoyer un signal à un
thread de façon _sûre_ ?
C'est simple : tu n'envoies pas de signal à un thread qui s'est déjà
terminé. C'est assez facile, parce que la condition « qui s'est déjà
terminée » pour le cas qui nous intéresse est active : ce n'est pas le fait
que le thread ait atteint pthread_exit qui compte, mais le fait qu'il ait
été achevé avec pthread_join, ou détaché avec pthread_detach.
Donc la démarche est simple : si tu fais un pthread_join ou un
pthread_detach sur un certain pthread_t, tu n'appelles plus pthread_kill
dessus. Idéalement, tu vires carrément le pthread_t de tes structures de
données, puisqu'il n'est de toutes façons plus valide. C'est valable aussi
pour un thread qui a été créé détaché (pthread_attr_setdetachstate).
Bien sûr, le mieux serait de t'abstenir d'utiliser des signaux avec des
threads, parce que c'est fondamentalement chercher les ennuis.
JKB wrote in message <slrngjlasl.bcl.knatschke@rayleigh.systella.fr>:
Je ne comprends pas pourquoi l'implantation threads posix sous Linux
ne renvoie pas ESRCH.
Ce que tu cites de la norme dit que la fonction _peut_ retourner cette
erreur, mais pas qu'elle _doit_ le faire. C'est assez systématique dans la
rédaction de ces normes, il faut en prendre l'habitude pour ne pas se
tromper.
n'étant pas ouvert à la discussion ou très peu
(http://sources.redhat.com/bugzilla/show_bug.cgi?id`)
Ulrich Drepper est imbuvable comme à son habitude, mais il n'a pas tort dans
ce qu'il dit dans le commentaire 4 : envoyer un signal à un thread qui
n'existe pas n'est pas une erreur de circonstance (comme un filesystem plein
ou un réseau inaccessible) mais une erreur dans la structure du programme :
si le programmeur a compris qu'il ne devait pas le faire, une fois son
programme débuggé, ça n'arrive plus.
Et si ça n'arrive pas dans un programme débuggé, alors on peut se dispenser
des tests dans la bibliothèque, ça fait que ça s'exécute plus vite. C'est
peu important pour une bibliothèque comme Gtk+ où de toutes façons il va y
avoir énormément de temps passé en communication avec le serveur X11 ou sur
le rendu de glyphes vectoriels, mais pour la libc, en particulier les
communications inter-threads, on s'attend à ce que ça aille le plus vite
possible.
Si tu veux débugger, tu lies tes programmes à une version de la glibc
compilée pour le débuggage. Il y a ce qu'il faut dans pthread_kill pour
détecter certaines des erreurs (et retourner ESRCH).
Note que, sous GNU, un thread_t est un pointeur, et pthread_kill le
déréférence. Donc autant tester un pointeur nul pour géré le cas du bug que
tu cites est facile, autant tester le cas d'un pointeur déjà libéré est
essentiellement impossible.
S'il s'agit d'un bug, comment faire pour envoyer un signal à un
thread de façon _sûre_ ?
C'est simple : tu n'envoies pas de signal à un thread qui s'est déjà
terminé. C'est assez facile, parce que la condition « qui s'est déjà
terminée » pour le cas qui nous intéresse est active : ce n'est pas le fait
que le thread ait atteint pthread_exit qui compte, mais le fait qu'il ait
été achevé avec pthread_join, ou détaché avec pthread_detach.
Donc la démarche est simple : si tu fais un pthread_join ou un
pthread_detach sur un certain pthread_t, tu n'appelles plus pthread_kill
dessus. Idéalement, tu vires carrément le pthread_t de tes structures de
données, puisqu'il n'est de toutes façons plus valide. C'est valable aussi
pour un thread qui a été créé détaché (pthread_attr_setdetachstate).
Bien sûr, le mieux serait de t'abstenir d'utiliser des signaux avec des
threads, parce que c'est fondamentalement chercher les ennuis.
JKB wrote in message :Je ne comprends pas pourquoi l'implantation threads posix sous Linux
ne renvoie pas ESRCH.
Ce que tu cites de la norme dit que la fonction _peut_ retourner cette
erreur, mais pas qu'elle _doit_ le faire. C'est assez systématique dans la
rédaction de ces normes, il faut en prendre l'habitude pour ne pas se
tromper.n'étant pas ouvert à la discussion ou très peu
(http://sources.redhat.com/bugzilla/show_bug.cgi?id`)
Ulrich Drepper est imbuvable comme à son habitude, mais il n'a pas tort dans
ce qu'il dit dans le commentaire 4 : envoyer un signal à un thread qui
n'existe pas n'est pas une erreur de circonstance (comme un filesystem plein
ou un réseau inaccessible) mais une erreur dans la structure du programme :
si le programmeur a compris qu'il ne devait pas le faire, une fois son
programme débuggé, ça n'arrive plus.
Et si ça n'arrive pas dans un programme débuggé, alors on peut se dispenser
des tests dans la bibliothèque, ça fait que ça s'exécute plus vite. C'est
peu important pour une bibliothèque comme Gtk+ où de toutes façons il va y
avoir énormément de temps passé en communication avec le serveur X11 ou sur
le rendu de glyphes vectoriels, mais pour la libc, en particulier les
communications inter-threads, on s'attend à ce que ça aille le plus vite
possible.
Si tu veux débugger, tu lies tes programmes à une version de la glibc
compilée pour le débuggage. Il y a ce qu'il faut dans pthread_kill pour
détecter certaines des erreurs (et retourner ESRCH).
Note que, sous GNU, un thread_t est un pointeur, et pthread_kill le
déréférence. Donc autant tester un pointeur nul pour géré le cas du bug que
tu cites est facile, autant tester le cas d'un pointeur déjà libéré est
essentiellement impossible.
S'il s'agit d'un bug, comment faire pour envoyer un signal à un
thread de façon _sûre_ ?
C'est simple : tu n'envoies pas de signal à un thread qui s'est déjà
terminé. C'est assez facile, parce que la condition « qui s'est déjà
terminée » pour le cas qui nous intéresse est active : ce n'est pas le fait
que le thread ait atteint pthread_exit qui compte, mais le fait qu'il ait
été achevé avec pthread_join, ou détaché avec pthread_detach.
Donc la démarche est simple : si tu fais un pthread_join ou un
pthread_detach sur un certain pthread_t, tu n'appelles plus pthread_kill
dessus. Idéalement, tu vires carrément le pthread_t de tes structures de
données, puisqu'il n'est de toutes façons plus valide. C'est valable aussi
pour un thread qui a été créé détaché (pthread_attr_setdetachstate).
Bien sûr, le mieux serait de t'abstenir d'utiliser des signaux avec des
threads, parce que c'est fondamentalement chercher les ennuis.
Dans la théorie, c'est bien. Dans la pratique, tester qu'un thread
fonctionne toujours n'est pas simple et se termine à grands coups de
mutexes avec une variable test. C'est _sale_,
alors que pthread_kill()
pourrait fonctionner comme kill().
Sauf que si tu cherches à utiliser pthread_kill(tid, 0), ce n'est
pas valable.
Je ne vois pas ce que pthread_detach vient faire là-dedans
vu ce qui est inscrit sur
<http://udrepper.livejournal.com/tag/programming+posix>
En théorie, c'est bien. En pratique, ce n'est pas forcément
faisable.
Dans la théorie, c'est bien. Dans la pratique, tester qu'un thread
fonctionne toujours n'est pas simple et se termine à grands coups de
mutexes avec une variable test. C'est _sale_,
alors que pthread_kill()
pourrait fonctionner comme kill().
Sauf que si tu cherches à utiliser pthread_kill(tid, 0), ce n'est
pas valable.
Je ne vois pas ce que pthread_detach vient faire là-dedans
vu ce qui est inscrit sur
<http://udrepper.livejournal.com/tag/programming+posix>
En théorie, c'est bien. En pratique, ce n'est pas forcément
faisable.
Dans la théorie, c'est bien. Dans la pratique, tester qu'un thread
fonctionne toujours n'est pas simple et se termine à grands coups de
mutexes avec une variable test. C'est _sale_,
alors que pthread_kill()
pourrait fonctionner comme kill().
Sauf que si tu cherches à utiliser pthread_kill(tid, 0), ce n'est
pas valable.
Je ne vois pas ce que pthread_detach vient faire là-dedans
vu ce qui est inscrit sur
<http://udrepper.livejournal.com/tag/programming+posix>
En théorie, c'est bien. En pratique, ce n'est pas forcément
faisable.