Ca n’a aucun sens, c’est comme si je te disait qu’il est impossible d’avoir des problèmes de concurrence sur un pentium 4 parce qu’il est monocoeur.
Ta section critique que t’es garantie qu’elle ne sera jamais interrompue, ça ne marche que si elle fait un traitement synchrone, i.e. qui bloque ton event loop. Bloquer une event loop, c’est mal, ça tue la latence, du coup on limite ça à des opérations très légères. Les opérations plus lourdes font un bout de processing, et rendent la main à l’event Loop, pour continuer leur processing à la boucle suivante. J’imagine que je ne t’apprends rien en disant ça.
Il suffit d’introduire un seul appel de fonction un tant soit peu costaud en cpu, genre un hash crypto, ou que sais je encore, et t’es force de repasser en asynchrone. Ta garantie que ta section critique ne sera pas interrompue vient de partir en fumée, et tu te retrouves avec du code méchamment bugge.
Dit autrement, ton approche marchotte tant que ton appli est triviale et/ou ne prend aucune charge (ce qui en pratique est la réalité de beaucoup d’appli node), et se ramasse/se bloque dès que tu monte en charge (ce qui est aussi en pratique la réalité de pas mal d’appli node), mais je pourrais dire exactement la même chose de n’importe quel modèle de programmation.
En pratique, le modèle "collaboratif", il te force à rendre la main en permanence, et t’es pas mieux loti qu’avec du préemptif. Ou alors, c’est que ton service n’est pas utilisé. C’est sur que n’avoir aucune charge aide a ne pas avoir de bugs, m’enfin, ça me paraît pas être flatteur, ni pertinent.
[^] # Re: Petit joueur
Posté par groumly . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2. Dernière modification le 09 mars 2018 à 08:21.
Ca n’a aucun sens, c’est comme si je te disait qu’il est impossible d’avoir des problèmes de concurrence sur un pentium 4 parce qu’il est monocoeur.
Ta section critique que t’es garantie qu’elle ne sera jamais interrompue, ça ne marche que si elle fait un traitement synchrone, i.e. qui bloque ton event loop. Bloquer une event loop, c’est mal, ça tue la latence, du coup on limite ça à des opérations très légères. Les opérations plus lourdes font un bout de processing, et rendent la main à l’event Loop, pour continuer leur processing à la boucle suivante. J’imagine que je ne t’apprends rien en disant ça.
Il suffit d’introduire un seul appel de fonction un tant soit peu costaud en cpu, genre un hash crypto, ou que sais je encore, et t’es force de repasser en asynchrone. Ta garantie que ta section critique ne sera pas interrompue vient de partir en fumée, et tu te retrouves avec du code méchamment bugge.
Dit autrement, ton approche marchotte tant que ton appli est triviale et/ou ne prend aucune charge (ce qui en pratique est la réalité de beaucoup d’appli node), et se ramasse/se bloque dès que tu monte en charge (ce qui est aussi en pratique la réalité de pas mal d’appli node), mais je pourrais dire exactement la même chose de n’importe quel modèle de programmation.
En pratique, le modèle "collaboratif", il te force à rendre la main en permanence, et t’es pas mieux loti qu’avec du préemptif. Ou alors, c’est que ton service n’est pas utilisé. C’est sur que n’avoir aucune charge aide a ne pas avoir de bugs, m’enfin, ça me paraît pas être flatteur, ni pertinent.