On Tue, Dec 29, 2020 at 05:53:07PM +0100, Marc Mongenet wrote:
Je réponds à Marc de manière générale, en me référant aux autres
derniers mails à ce sujet.
Je n'étais jamais tombé sur la confusion entre thread et processus
avant aujourd'hui.
Moi non plus (uniquement la formulation générale "c'est du multithread"
qui est suffisamment vague pour signifer tout).
Il y a en effet confusion et c'est ce qui a engendré ma réponse à Félix.
Comme Marc l'a dit, le multi-thread a longtemps été boudé par le monde
UNIX et c'est, il me semble, dans les première versions Berkeley que
l'on a vu arrivé les "threads" sous UNIX. Jusque là, on ne disposait que
des outils classiques de multi-processing avec fork/exec et les
shm/sem/msg pour les gérer.
Peut-être que par chance cette confusion entre thread et processus
reste cantonnée à la littérature sur Bash?
On parle plutôt de jobs et de jobs control, dans bash, que de thread ou
de processus. Ce sont bien sûr des processus, bash n'étant à ma
connaissance pas multithreadé (au sens thread usuel).
En effet, bash n'est pas en mesure de gérer des "threads". Il est donc
faux de parler de multi-thread en bash.
La confusion est entretenue par plein de gens qui n'ont pas compris les
différences entre les deux. Ce n'est pas vraiment une grosse différence
au niveau du kernel, mais une différence de la manière dont l'un ou
l'autre sont gérés. Tout process a au moins un thread (le maître) et
tous les autres threads doivent être créés à partir de celui-ci. Un
thread partage donc la mémoire (intégralement, y compris la shered
memory) avec les autres threads, ainsi que les fichiers du programme
principal. Un thread a donc son propre stack, mais il n'y a pas de
duplication de code/data comme avec un fork. Si un thread ferme un
fichier, celui-ci se ferme aussi pour les autres threads, y compris le
process principal. A contrario, lors d'un fork, on hérite des fichiers
du programme appelant, mais en ayant des structures différentes ainsi
que toute les segments data entièrement indépendants. Ce qui fait que si
l'on ferme un fichier dans le processus issu d'un fork, ceci n'affecte
en rien le programme appelant. Il y donc un lien très fort en entre les
threads, alors que ce lien n'existe pas entre des processus issus d'un
fork. Autre exemple, on peut envoyer un signal a un process, et seul
celui-ci sera affecté, alors que si l'on envoie un SIGTERM à un thread
(pthread_kill) on tue ce thread et le process qui l'héberge... tuant
aussi tous les autres threads associés à celui-ci. On voit donc que les
threads sont très orientés "synchrone", alors que les process (PID) sont
avant tout orientés de manière à être indépendants et asynchrones (sans
que l'on soit empêcher de passer d'un mode à un autre).
La confusion est sans doute issue du monde Java qui fait un usage très
intense des "threads" en négligeant totalement que dans certains cas le
multi-process pourrait être plus efficace (le compilateur ayant aussi de
la peine à comprendre une écriture logique et propre de la séquence
bind/accept/select). Il y a donc toute une génération qui ne comprend
que les threads et qui ne parle que de ça.
Pour que ce soit bien compris par les autres lecteurs silencieux de la
liste, il existe plein d'articles qui expliquent ces différences sur le
net, dont :
https://linux-attitude.fr/post/processus-et-threads
Donc, à partir du moment où un fait un fork... on fait du
multi-processing et non du multi-threading. Deuxièmement, à partir du
moment où on ne peut pas échanger les valeurs au travers de symboles
(variable) partagées, et que l'on est donc obligé d'avoir recours à un
file/socket pour le faire, on est aussi en multi-process et non en
multi-thread.
Le script de Félix est donc du multi-process, et non du multi-threading.
Il partage élégamment des fichiers pour échanger des informations et
utilise un fork/exec (ping); ce qui le place en effet dans la notion de
multi-process .
Pour bien comprendre ces différences, j'encourage quiconque à pratiquer
un peu de code dans les deux modes avec un langage permettant le
multi-threading, comme Python, C/C++, Java (et d'autres mais pas PHP, ni
Perl, ni Bash). Par exemple :
https://www.tutorialspoint.com/python/python_multithreading.htm
Bonne soirée
dc
_______________________________________________
gull mailing list
[email protected]
https://forum.linux-gull.ch/mailman/listinfo/gull
