L'article est intéressant, mais je trouve que la gravité du "problème" évoqué n'est absolument pas en rapport avec la popularité de l'article.
Tout d'abord, la solution que préfère l'auteur (dernier paragraphe) sont les green threads. Ce n'est pas une meilleure solution mais un compromis différent, comme dit dans mon journal (besoin de gérer la synchronisation à la main, overhead sur chaque thread, profil de performance différent). Certes il n'y a plus le sujet du function coloring au niveau du langage, mais encore faut-il que les autres compromis conviennent.
Sur le fond, la raison principale pour laquelle le function coloring n'est pas un vrai problème, c'est que dans un programme bien architecturé, l'I/O est en haut de l'arbre des appels, et qu'au fur et à mesure qu'on rentre dedans on essaie d'avoir des fonctions pures, ou plus généralement qui peuvent facilement être testées.
D'ailleurs le function coloring n'est pas spécifique à async/await : une fonction qui prend en premier argument une connexion à la base de données, ou encore une référence à la requête en cours ne peut pas être appelée par une fonction qui n'a pas cette référence. Certes dans ce cas il y a des façons simples d'éviter le problème comme utiliser un singleton, du thread-local storage ou équivalent, mais ce n'est pas forcément une solution propre ou souhaitable.
Pour moi le seul cas où il y a un vrai problème est si l'on doit appeler une fonction async à partir d'une librairie qui ne le prévoit pas, par exemple un validateur XML qui permet de fournir un callback pour vérifier certains éléments, et on souhaite dans ce callback appeler un service web. Mais, en pratique, du moins dans l'écosystème node.js, c'est extrêmement marginal (personnellement je n'ai jamais vu le problème), et, vu que la grande majorité des librairies sont opensource il est facile de les modifier pour avoir le comportement qu'on souhaite.
Et, enfin, ce n'est pas vrai qu'il n'est pas possible d'appeler des fonctions async à partir d'une fonction sync. Ce n'est pas une bonne idée vu que ça bloque l'event loop, mais, par exemple en Node.js ça peut être fait en exécutant la fonction dans un worker thread et en attendant son résultat avec Atomics.wait.
[^] # Re: What color is your function ?
Posté par fork_bomb . En réponse au journal Pourquoi le modèle de concurrence de Node.js est bien. Évalué à 2 (+2/-1).
L'article est intéressant, mais je trouve que la gravité du "problème" évoqué n'est absolument pas en rapport avec la popularité de l'article.
Tout d'abord, la solution que préfère l'auteur (dernier paragraphe) sont les green threads. Ce n'est pas une meilleure solution mais un compromis différent, comme dit dans mon journal (besoin de gérer la synchronisation à la main, overhead sur chaque thread, profil de performance différent). Certes il n'y a plus le sujet du function coloring au niveau du langage, mais encore faut-il que les autres compromis conviennent.
Sur le fond, la raison principale pour laquelle le function coloring n'est pas un vrai problème, c'est que dans un programme bien architecturé, l'I/O est en haut de l'arbre des appels, et qu'au fur et à mesure qu'on rentre dedans on essaie d'avoir des fonctions pures, ou plus généralement qui peuvent facilement être testées.
D'ailleurs le function coloring n'est pas spécifique à async/await : une fonction qui prend en premier argument une connexion à la base de données, ou encore une référence à la requête en cours ne peut pas être appelée par une fonction qui n'a pas cette référence. Certes dans ce cas il y a des façons simples d'éviter le problème comme utiliser un singleton, du thread-local storage ou équivalent, mais ce n'est pas forcément une solution propre ou souhaitable.
Pour moi le seul cas où il y a un vrai problème est si l'on doit appeler une fonction async à partir d'une librairie qui ne le prévoit pas, par exemple un validateur XML qui permet de fournir un callback pour vérifier certains éléments, et on souhaite dans ce callback appeler un service web. Mais, en pratique, du moins dans l'écosystème node.js, c'est extrêmement marginal (personnellement je n'ai jamais vu le problème), et, vu que la grande majorité des librairies sont opensource il est facile de les modifier pour avoir le comportement qu'on souhaite.
Et, enfin, ce n'est pas vrai qu'il n'est pas possible d'appeler des fonctions async à partir d'une fonction sync. Ce n'est pas une bonne idée vu que ça bloque l'event loop, mais, par exemple en Node.js ça peut être fait en exécutant la fonction dans un worker thread et en attendant son résultat avec Atomics.wait.