Sans doute mais tu commences par "je ne suis pas d'accord" pour au final complété quelque chose et corriger quelques détails.
Je ne suis pas d'accord pour dire que si on a pas d'implémentation asynchrone de bout en bout, on lance des threads systèmes ou des process. En aucune manière, même pas une solution du pauvre. Ça adresse des problématiques différentes. Je pense que c'est quand même dis clairement dans mes 2 commentaires.
Je ne vois pas en quoi ça améliore le context switching.
Tu ne déclenche pas de contexte switch en passant d'un green thread à un autre (ils sont coopératifs). Je pense que c'est ce qu'entends wikipedia par thread activation. Donc tu l'évite tout simplement. Si tu implémente le switch entre green thread par des contexte switch OS ce sont des threads systèmes.
D'après https://en.wikipedia.org/wiki/Green_threads#Performance, c'est même l'inverse et ça me parait logique vu que c'est une couche d’abstraction en plus et que ça ne tiens pas en compte du matériel (mono CPU et pas de prise en compte du multi-threading physique)
Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés... C'est assez logique. C'est pour ça que les implémentations actuels traduisent toutes tes opérations en asynchrones. Je le disais peut être pas de la même façon dans mon premier commentaire.
Pour ce qui est des IO, en terme de débit les api synchrones sont meilleures. Mais pour la latence quand tu reçois un paquet de requêtes c'est la latence qui t'intéresse plus que le débit.
Après, entre la définition (d'ailleurs chaque langage a un peu son nom a lui), l'implémentation (pareil, très fluctuent) et ce que ça fait réellement.
A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.
[^] # Re: Des bonnes idées
Posté par barmic 🦦 . En réponse à la dépêche Les nouvelles fonctionnalités de PHP 8. Évalué à 2.
Je ne suis pas d'accord pour dire que si on a pas d'implémentation asynchrone de bout en bout, on lance des threads systèmes ou des process. En aucune manière, même pas une solution du pauvre. Ça adresse des problématiques différentes. Je pense que c'est quand même dis clairement dans mes 2 commentaires.
Tu ne déclenche pas de contexte switch en passant d'un green thread à un autre (ils sont coopératifs). Je pense que c'est ce qu'entends wikipedia par thread activation. Donc tu l'évite tout simplement. Si tu implémente le switch entre green thread par des contexte switch OS ce sont des threads systèmes.
Ce que dit wikipedia c'est qu'un process qui tiens 25 green thread qui se fait prempt va prempt les 15greens threads seront préemptés... C'est assez logique. C'est pour ça que les implémentations actuels traduisent toutes tes opérations en asynchrones. Je le disais peut être pas de la même façon dans mon premier commentaire.
Pour ce qui est des IO, en terme de débit les api synchrones sont meilleures. Mais pour la latence quand tu reçois un paquet de requêtes c'est la latence qui t'intéresse plus que le débit.
A part la réimplémentation ou non des appels synchrones, je n'ai pas vu tant de différence.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll