c'est bien ce que je reproche c'est du parallélisme plus que de l'asynchrone. Le fait que ce soit parallèle ou pas est un détail pas un besoin fonctionnel.
Pour moi l'asynchrone est un mécanisme de programmation parallèle au même titre de la concurrence. Dans le premier cas (l'asynchrone) un seul traitement est réalisé à un moment donné contre plusieurs dans le second (et encore, à condition d'avoir plusieurs cœurs physiques...), mais ça c'est justement des détails et pas un besoin fonctionnel.
À contrario parler de parallélisme c'est parler d'un besoin fonctionnel (exemple: j'ai besoin de faire tourner ma gui et mon code applicatif en parallèle)
ça gère que si l’une des deux branches se plante, il faut interrompre l’autre => ouf ça veut dire quoi ? Je veux dire, il va préempter ton code et tout interrompre ? C'est particulièrement dangereux.
Si une des deux branches se plante ça veut dire qu'on est dans un état qui mérite un traitement particulier, ça peut être arrêter toutes les coroutines jusqu'à un certain niveau, retenter de zéro la traitement de la coroutine ayant échoué et bien encore ne rien etc.
L'important c'est surtout de se dire qu'il y a nécessairement besoin de faire quelque chose (ce qui peut être "ne rien faire" mais dans ce cas on le fait en connaissance de cause) et pas juste balancer une stacktrace dans stdout et faire comme si de rien n'était, ce qui est malheureusement la façon de faire de bien trop de frameworks parallèles.
Ensuite effectivement une fois qu'on sait ce qu'on doit arrêter, encore faut-il le faire proprement. À ce niveau trio injecte une exception CancelledError dans la coroutine à terminer, ce qui permet à celle-ci de se nettoyer proprement, voir même d'annuler son arrêt si le cœur lui en dit (mais encore une fois ça dépend totalement du cas d'usage).
mais quand tu fais du twist, tu es massivement asynchrone.
j'imagine que tu parles de twisted ?
Remonter dans le contexte principal à chaque fois que quelque chose se passe mal est intenable.
Je n'ai pas compris ce que tu voulais dire par contexte principal ? Dans un framework asynchrone lambda une fois l'event loop lancée il n'y a pas une coroutine plus principale qu'une autre. Et de toute façon l'event loop en question passe déjà son temps à switcher d'une coroutine à une autre donc je ne vois pas en quoi aller dans un contexte supplémentaire serait intenable...
Il faut réduire le scope de tes actions et chercher à porter les informations dans des messages plus que dans un état.
C'est justement la force des nursery, cela te permet de créer des scope regroupant tes coroutines. Et donc De fait quand une coroutine plante ça remonte ton arbre de scopes (en arrêtant les coroutines en bonne ordre dans la foulée) jusqu'à ce que un try/except veuille bien s'en occuper. Si personne ne veut s'en occuper, ben ton programme crash. Et c'est bien normal, explicit is better than implicit comme ils disent.
La gestion d'un état dans un monde asynchrone est sincèrement dangereux parce qu'il est difficile de s'assurer qu'il reste cohérent quelque soit l'ordre dans le quel tes actions asynchrones se résolvent.
Tout à fait d'accord. Malgré tout c'est parfois difficile de travailler uniquement avec un système de messages (typiquement dans le cas d'une base de donnée qui doit pouvoir traiter plusieurs requêtes en parallèle alors que celles-ci travaillent sur les mêmes données).
Dans ces cas là l'asynchrone apporte un gros avantage par rapport à la programmation concurrente puisque les points de concurrences sont explicites (i.e. tant qu'on ne met pas un await dans le code on a la garantie que personne ne va faire des choses dans notre dos). Évidemment cela n'est pas gratuit et a ses propres limitations (si la base de donnée de l'exemple précédent fait des traitements lourds en CPU par exemple)
Et dans tous les cas, tu peux parfaitement utiliser trio pour faire du passement de messages, les nursery te permettent juste de mieux organiser ton système. Comme par exemple pour gérer proprement ce qui doit se passer quand un point de traitement de tes messages crash...
[^] # Re: Rx
Posté par G.bleu (site web personnel) . En réponse au journal La programmation concurrente en mode Goto. Évalué à 3.
Pour moi l'asynchrone est un mécanisme de programmation parallèle au même titre de la concurrence. Dans le premier cas (l'asynchrone) un seul traitement est réalisé à un moment donné contre plusieurs dans le second (et encore, à condition d'avoir plusieurs cœurs physiques...), mais ça c'est justement des détails et pas un besoin fonctionnel.
À contrario parler de parallélisme c'est parler d'un besoin fonctionnel (exemple: j'ai besoin de faire tourner ma gui et mon code applicatif en parallèle)
Si une des deux branches se plante ça veut dire qu'on est dans un état qui mérite un traitement particulier, ça peut être arrêter toutes les coroutines jusqu'à un certain niveau, retenter de zéro la traitement de la coroutine ayant échoué et bien encore ne rien etc.
L'important c'est surtout de se dire qu'il y a nécessairement besoin de faire quelque chose (ce qui peut être "ne rien faire" mais dans ce cas on le fait en connaissance de cause) et pas juste balancer une stacktrace dans stdout et faire comme si de rien n'était, ce qui est malheureusement la façon de faire de bien trop de frameworks parallèles.
Ensuite effectivement une fois qu'on sait ce qu'on doit arrêter, encore faut-il le faire proprement. À ce niveau trio injecte une exception CancelledError dans la coroutine à terminer, ce qui permet à celle-ci de se nettoyer proprement, voir même d'annuler son arrêt si le cœur lui en dit (mais encore une fois ça dépend totalement du cas d'usage).
j'imagine que tu parles de twisted ?
Je n'ai pas compris ce que tu voulais dire par contexte principal ? Dans un framework asynchrone lambda une fois l'event loop lancée il n'y a pas une coroutine plus principale qu'une autre. Et de toute façon l'event loop en question passe déjà son temps à switcher d'une coroutine à une autre donc je ne vois pas en quoi aller dans un contexte supplémentaire serait intenable...
C'est justement la force des nursery, cela te permet de créer des scope regroupant tes coroutines. Et donc De fait quand une coroutine plante ça remonte ton arbre de scopes (en arrêtant les coroutines en bonne ordre dans la foulée) jusqu'à ce que un try/except veuille bien s'en occuper. Si personne ne veut s'en occuper, ben ton programme crash. Et c'est bien normal, explicit is better than implicit comme ils disent.
Tout à fait d'accord. Malgré tout c'est parfois difficile de travailler uniquement avec un système de messages (typiquement dans le cas d'une base de donnée qui doit pouvoir traiter plusieurs requêtes en parallèle alors que celles-ci travaillent sur les mêmes données).
Dans ces cas là l'asynchrone apporte un gros avantage par rapport à la programmation concurrente puisque les points de concurrences sont explicites (i.e. tant qu'on ne met pas un await dans le code on a la garantie que personne ne va faire des choses dans notre dos). Évidemment cela n'est pas gratuit et a ses propres limitations (si la base de donnée de l'exemple précédent fait des traitements lourds en CPU par exemple)
Et dans tous les cas, tu peux parfaitement utiliser trio pour faire du passement de messages, les nursery te permettent juste de mieux organiser ton système. Comme par exemple pour gérer proprement ce qui doit se passer quand un point de traitement de tes messages crash...