[gull] Truc et astuces: multithread en bash

[Daniel Cordey]

> 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