Merci pour votre travail!
Je lis un peu le code, étant un éternel débutant en Rust, et je mesure le chemin qui me reste à parcourir pour être capable d'écrire de manière aussi élégante et concise!
Oh malheureux, si tu avais vu mes premiers drafts :)
Rust async est un peu ma bête noire, car c'est fondamentalement différent de Rust sync. Petit exemple :
Avec Rust sync, j'ai tendance a vouloir passer mes données par référence, pour éviter de consommer inutilement de la mémoire.
Parfois, cela veut dire d'utiliser RefCell<_> comme type pour un champ d'une structure et donc de déléguer au runtime (au lieu du compile time) la vérification des invariants (aka: oui, je suis bien le seul a vouloir modifier cette valeur à l'instant t).
L'équivalent async, c'est Arc<Mutex<_>> qui arrive avec son lot de problèmes. La mutex possède un lock, et je me suis retrouvé dans une situation ou j'avais une tâche asynchrone (tokio::spawn) qui avait besoin de lock la mutexe durant toute sa durée de vie, rendant la resource derrière inutilisable par toute autre tâches asynchrone. Aïe, aïe, aïe.
Du coup, au lieu d'essayer de partager une donnée entre plusieurs tâches asynchrone via des références, j'ai mis en place un système de canaux pour échanger les informations nécessaire pour que chaque tâche puisse faire son travail. Cela a voulu dire transformer certaines fonctions en tâche asynchrone, et cloner des mpsc::Sender<_> à droite à gauche, au lieu d'essayer de partager un Arc<Mutex<_>> correctement.
A et aussi rendre une structure clonable et la dupliquer plus que nécessaire, par flemme.
Au final, quand je code en "Rust sync", mon cerveau est en mode "fonctionnel à la C/C++".
Quand je fais du code en "Rust async", je dois passer mon cerveau en mode "Erlang/Elixir".
Je suis loin d'être un expert, et ce code est loin d'être le mieux qui soit, plein d'axe d'amélioration. Heureusement, ce cas d'usage n'est pas critique concernant la performance en temps CPU et en RAM utilisée. Le léger overhead que j'introduis devrait être négligeable (bien que optimisable).
Au début je me suis dis que c'était un peu violent pour simplement changer le comportement par défaut de supervisord, mais je comprends pour le runtime.
Et puis la philosophie n'est probablement pas la même :
supervisord est fait pour utiliser des conteneur un peu comme des vm. Tu prends ta debian, tu install ce dont tu as besoin dessus et c'est parti.
procfusion est plus pour des services qui sont regroupés (ce qui aujourd'hui est plutôt géré par la notion de pod)
procfusion est plus pour des services qui sont regroupés (ce qui aujourd'hui est plutôt géré par la notion de pod)
Dans 95% des cas, recourir à supervisord/procfusion dans un conteneur Docker, c'est un anti-pattern et un symptôme d'un conteneur qui devrait être splitté.
Je suis pas sûr de ce que tu entend par "pod" (mon cerveau influencé par kubernetes entend: un ensemble de conteneur), si on a la même définition alors on est d'accord : plusieurs services = plusieurs conteneurs.
Cependant, un service != un processus. Dans 95% des cas oui, mais dans les 5% restant, pas forcément. Comme par exemple un petit processus qui surveille un point de montage de volume avec inotify pour appeler nginx -s reload quand un certificat TLS est renouvelé.
# excellent!
Posté par bistouille . Évalué à 3.
Merci pour votre travail!
Je lis un peu le code, étant un éternel débutant en Rust, et je mesure le chemin qui me reste à parcourir pour être capable d'écrire de manière aussi élégante et concise!
[^] # Re: excellent!
Posté par David Delassus (site web personnel) . Évalué à 5.
Merci pour le retour :)
Oh malheureux, si tu avais vu mes premiers drafts :)
Rust async est un peu ma bête noire, car c'est fondamentalement différent de Rust sync. Petit exemple :
Avec Rust sync, j'ai tendance a vouloir passer mes données par référence, pour éviter de consommer inutilement de la mémoire.
Parfois, cela veut dire d'utiliser
RefCell<_>comme type pour un champ d'une structure et donc de déléguer au runtime (au lieu du compile time) la vérification des invariants (aka: oui, je suis bien le seul a vouloir modifier cette valeur à l'instant t).L'équivalent async, c'est
Arc<Mutex<_>>qui arrive avec son lot de problèmes. La mutex possède un lock, et je me suis retrouvé dans une situation ou j'avais une tâche asynchrone (tokio::spawn) qui avait besoin de lock la mutexe durant toute sa durée de vie, rendant la resource derrière inutilisable par toute autre tâches asynchrone. Aïe, aïe, aïe.Du coup, au lieu d'essayer de partager une donnée entre plusieurs tâches asynchrone via des références, j'ai mis en place un système de canaux pour échanger les informations nécessaire pour que chaque tâche puisse faire son travail. Cela a voulu dire transformer certaines fonctions en tâche asynchrone, et cloner des
mpsc::Sender<_>à droite à gauche, au lieu d'essayer de partager unArc<Mutex<_>>correctement.A et aussi rendre une structure clonable et la dupliquer plus que nécessaire, par flemme.
Au final, quand je code en "Rust sync", mon cerveau est en mode "fonctionnel à la C/C++".
Quand je fais du code en "Rust async", je dois passer mon cerveau en mode "Erlang/Elixir".
Je suis loin d'être un expert, et ce code est loin d'être le mieux qui soit, plein d'axe d'amélioration. Heureusement, ce cas d'usage n'est pas critique concernant la performance en temps CPU et en RAM utilisée. Le léger overhead que j'introduis devrait être négligeable (bien que optimisable).
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
# supervisord
Posté par barmic 🦦 . Évalué à 4.
Au début je me suis dis que c'était un peu violent pour simplement changer le comportement par défaut de supervisord, mais je comprends pour le runtime.
Et puis la philosophie n'est probablement pas la même :
supervisord est fait pour utiliser des conteneur un peu comme des vm. Tu prends ta debian, tu install ce dont tu as besoin dessus et c'est parti.
procfusion est plus pour des services qui sont regroupés (ce qui aujourd'hui est plutôt géré par la notion de pod)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: supervisord
Posté par David Delassus (site web personnel) . Évalué à 5.
Dans 95% des cas, recourir à supervisord/procfusion dans un conteneur Docker, c'est un anti-pattern et un symptôme d'un conteneur qui devrait être splitté.
Je suis pas sûr de ce que tu entend par "pod" (mon cerveau influencé par kubernetes entend: un ensemble de conteneur), si on a la même définition alors on est d'accord : plusieurs services = plusieurs conteneurs.
Cependant, un service != un processus. Dans 95% des cas oui, mais dans les 5% restant, pas forcément. Comme par exemple un petit processus qui surveille un point de montage de volume avec
inotifypour appelernginx -s reloadquand un certificat TLS est renouvelé.procfusion, c'est pour ce cas là précisément.
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.