[gull] Truc et astuces: multithread en bash

[Daniel Cordey]

On 28/12/2020 21:44, felix wrote:
>
> Je m'attendais à cette remarque!

:-)


> Du point de vue du script lui même, il converse *effectivement* avec au moins
> deux thread indépendant: Les pings et l'utilisateur
>
>     $ cat -n multiping.sh | grep read\ -
>      18      read -u ${fds[$1]} -r line
>      55      if read -rsn 1 -t .2 key ;then
>      62          read -t 0 -u ${fds[i]} && pingInput $i

C'est juste là que notre vocabulaire diffère. Tu me diras qu'il s'agit 
d'une question de sémantique, mais elle a son importance (à mes yeux), 
car je vois trop de confusion de la part de plein de gens qui parlent de 
l'un en utilisant l'autre. C'est qu'il y a une différence fondamentale 
entre les deux et cette confusion entretenue fait que les gens pense que 
le multi-threading est la solution et ne réfléchissent jamais autrement. 
Dans ton cas, oui, tu lis (depuis le shell d'origine) le contenu d'un 
fichier, lui-même mis à jour par... un process et non un "thread" ! Un 
"thread" n'est pas un process et inversement. Et l'un n'est pas non plus 
le dérivé de l'autre.

En écrivant :

exec {fd} <(ping ...)

Tu fais un fork, suivit d'un exec du code /usr/bin/ping. Donc un autre 
PID -> autre process -> Pas un thread !

Ce qui est entre les deux (...) est un sub-shell, donc un autre process, 
et non un thread. Le problème vient sans doute d'un abus de langage très 
répandu dans la littérature qui parle de thread et de coroutines pour 
bash. Or, c'est à mon avis n'importe quoi. Les threads (en bash) sont 
tous des process séparés auxquels on attribue le mot de "thread", et les 
coroutines ne sont que ce que tu fais exactement dans ton script. Cette 
soit-disant vulgarisation apporte énormément d'ambiguïté et ne fait que 
répandre de faux concepts auprès des programmeurs. Tu mentionnes aussi 
la commande select() (system call, pas le 'select' de bash), qui est une 
composante essentielle dans le multi-processing. Or, bash, comme tu le 
dis, n'a pas cette commande et tu as justement développé une solution 
élégante pour t'en passer. Mais avec un vrai thread, on n'a pas besoin 
de passer par un fichier pour échanger les données, puisque l'on peut 
directement écrire dans la mémoire du process ayant initié le thread. 
C'est là qu'est toute la différence.

Le multi-threading répond à des besoins bien précis, alors que le 
multi-processing répond à d'autre besoins. Les deux sont complémentaires 
et ne doivent pas être confondus. Reste que bash offre beaucoup de 
facilité pour chaîner les process et, comme tu l'as démontré, qu'il est 
possible de synchroniser l'échange de données entre process (quoiqu'il 
s'agisse de polling dans ce cas et pas d'asynchronisme). Mais bash, n'a 
aucune capacité permettant à faire du multi-threading.

Ce que tu dis au sujet de l'espace disque avec de grosse quantités de 
données est juste. Ce fut aussi le sujet d'une discussion il y a 
quelques années à props du gain de performance en utilisant des pipes 
sur des systèmes multi-core :-)


A+

dc