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
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
