Tout ce que je peux dire c'est que j'ai eu le problème de Chris il y a des années, et que je l'ai résolu en utilisant la méthode que j'ai préconisé ... mais pas inventé ... puisqu'on me l'a préconisé auparavant.
join apporte l'assurance que tous les threads sont sortis correctement ... et donc dans le cas présent qu'ils ont géré la fermeture de leurs sockets respectifs d'une façon que le développeur maîtrise.
De toute façon, il me semblait que les sockets clients étaient fermés directement par le thread principal avant que le programme quitte. Je ne vois pas ce qui peut mal se passer dans ce cas, même si un thread fou ne répond plus. Une fois l'application quittée, tout sera nettoyé par l'OS de toute façon.
Quelque part, ça me fait peut-être mieux comprendre pourquoi il n'y a pas de "kill-thread" en Python ... mais ce n'est surement pas l'unique raison.
Ce n'est pas une limitation du Python en tout cas. Par exemple, la lib SDL qui fournit un accès multi-platforme aux threads pour du code C ne fournit pas non plus cette opération pour les mêmes raisons.
Tout ce que je peux dire c'est que j'ai eu le problème de Chris il y a
des années, et que je l'ai résolu en utilisant la méthode que j'ai
préconisé ... mais pas inventé ... puisqu'on me l'a préconisé auparavant.
join apporte l'assurance que tous les threads sont sortis correctement
... et donc dans le cas présent qu'ils ont géré la fermeture de leurs
sockets respectifs d'une façon que le développeur maîtrise.
De toute façon, il me semblait que les sockets clients étaient fermés
directement par le thread principal avant que le programme quitte. Je ne
vois pas ce qui peut mal se passer dans ce cas, même si un thread fou ne
répond plus. Une fois l'application quittée, tout sera nettoyé par l'OS de
toute façon.
Quelque part, ça me fait peut-être mieux comprendre pourquoi il n'y a pas
de "kill-thread" en Python ... mais ce n'est surement pas l'unique
raison.
Ce n'est pas une limitation du Python en tout cas. Par exemple, la lib SDL
qui fournit un accès multi-platforme aux threads pour du code C ne fournit
pas non plus cette opération pour les mêmes raisons.
Bon, mais tu es d'accord que tout OS compatible Posix doit pouvoir le
supporter ? ex: http://www.cs.cf.ac.uk/Dave/C/node32.html
Tout ce que je peux dire c'est que j'ai eu le problème de Chris il y a des années, et que je l'ai résolu en utilisant la méthode que j'ai préconisé ... mais pas inventé ... puisqu'on me l'a préconisé auparavant.
join apporte l'assurance que tous les threads sont sortis correctement ... et donc dans le cas présent qu'ils ont géré la fermeture de leurs sockets respectifs d'une façon que le développeur maîtrise.
De toute façon, il me semblait que les sockets clients étaient fermés directement par le thread principal avant que le programme quitte. Je ne vois pas ce qui peut mal se passer dans ce cas, même si un thread fou ne répond plus. Une fois l'application quittée, tout sera nettoyé par l'OS de toute façon.
Quelque part, ça me fait peut-être mieux comprendre pourquoi il n'y a pas de "kill-thread" en Python ... mais ce n'est surement pas l'unique raison.
Ce n'est pas une limitation du Python en tout cas. Par exemple, la lib SDL qui fournit un accès multi-platforme aux threads pour du code C ne fournit pas non plus cette opération pour les mêmes raisons.
Bah tu remarqueras dans cette page que la fonction thr_kill ne tue pas un thread, pas plus que la commande kill ne tue un process en Unix.
L'utilitaire standard kill mérite probablement la palme de la fonction la plus mal nommée des environnements Unix, et pourtant, c'est pas ce qui manque :D kill ne tue pas un processus mais il lui envoi un simple signal.
hg wrote:
Bon, mais tu es d'accord que tout OS compatible Posix doit pouvoir le
supporter ? ex: http://www.cs.cf.ac.uk/Dave/C/node32.html
Bah tu remarqueras dans cette page que la fonction thr_kill ne tue pas un
thread, pas plus que la commande kill ne tue un process en Unix.
L'utilitaire standard kill mérite probablement la palme de la fonction la
plus mal nommée des environnements Unix, et pourtant, c'est pas ce qui
manque :D kill ne tue pas un processus mais il lui envoi un simple signal.
Bah tu remarqueras dans cette page que la fonction thr_kill ne tue pas un thread, pas plus que la commande kill ne tue un process en Unix.
L'utilitaire standard kill mérite probablement la palme de la fonction la plus mal nommée des environnements Unix, et pourtant, c'est pas ce qui manque :D kill ne tue pas un processus mais il lui envoi un simple signal.
Bah tu remarqueras dans cette page que la fonction thr_kill ne tue pas un thread, pas plus que la commande kill ne tue un process en Unix.
L'utilitaire standard kill mérite probablement la palme de la fonction la plus mal nommée des environnements Unix, et pourtant, c'est pas ce qui manque :D kill ne tue pas un processus mais il lui envoi un simple signal.
Et si le processus ne gère pas le signal (ex: kill -9 ) alors il est terminé pas l'OS sans autre forme de procès.
hg
Christophe Cavalaria wrote:
hg wrote:
Bon, mais tu es d'accord que tout OS compatible Posix doit pouvoir le
supporter ? ex: http://www.cs.cf.ac.uk/Dave/C/node32.html
Bah tu remarqueras dans cette page que la fonction thr_kill ne tue pas un
thread, pas plus que la commande kill ne tue un process en Unix.
L'utilitaire standard kill mérite probablement la palme de la fonction la
plus mal nommée des environnements Unix, et pourtant, c'est pas ce qui
manque :D kill ne tue pas un processus mais il lui envoi un simple signal.
Et si le processus ne gère pas le signal (ex: kill -9 ) alors il est terminé
pas l'OS sans autre forme de procès.
Bah tu remarqueras dans cette page que la fonction thr_kill ne tue pas un thread, pas plus que la commande kill ne tue un process en Unix.
L'utilitaire standard kill mérite probablement la palme de la fonction la plus mal nommée des environnements Unix, et pourtant, c'est pas ce qui manque :D kill ne tue pas un processus mais il lui envoi un simple signal.
Et si le processus ne gère pas le signal (ex: kill -9 ) alors il est terminé pas l'OS sans autre forme de procès.