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).
[^] # Re: excellent!
Posté par David Delassus (site web personnel) . En réponse au lien procfusion - Un gestionnaire de processus, écrit en Rust, pour vos images Docker. É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