De mon point de vue, il y a d'un côté la programmation événementielle, avec un seul thread, une boucle événementielle et des callbacks (potentiellement abstraits via des promises, futures, observables).
Là tu décris le paterne reactor. C'est une façon de faire de l'évènementiel. On doit pouvoir dire qu'il s'agit de tout ce qui est réactif.
Et de l'autre côté, on a des modèles qui s'exécutent sur plusieurs threads et du parallélisme.
Il y a un tas de façons de gérer ça donc à part dire que c'est de la programmation parallèle, je ne vois pas bien quoi en dire de plus.
Pour les serveurs où les performances (et notamment la latence) sont importantes, j'ai l'impression que le premier modèle est nettement en déclin (la hype, c'était plutôt vers 2010-2013), avec notamment beaucoup de Go.
Je n'ai pas réussi à trouver l'architecture interne de haproxy ou de sozu [...] je viens de trouver une conférence d'un développeur de sozu. Je te l'ai mis au timecode qui parle de ça, ils font de l'eventloop monothread. Pour ceux qui ne connaissent pas sozu est un reverse proxy sorti l'an dernier (et open source) dont l'objectif est la performance et la capacité à n'avoir aucune downtime y compris lors de ses mises à jour et des changements de configuration. Ils l'ont écris en rust et sont d'abord aller voir ce qu'il y avait sur le marché. Je pense qu'on peut dire qu'ils ont une bonne vision de l'état de l'art du domaine (et au passage il explique que haproxy (comme nginx) est aussi une eventloop monothread).
Je connais mal les green threads comment ils se comportent par rapport aux contexte switch ? Je veux dire :
comment le runtime d'un langage est plus à même de faire des choix que CFS ?
comment se comporte le contexte swicth ? c'est juste qu'on reste dans l'espace utilisateur ?
comment cela se passe par rapport aux caches CPU ?
Tu aurais un exemple de service qui traite un paquet de requêtes en go par exemple ? J'aimerais bien regarder le modèle de threading utilisé.
Nodejs a plutôt l'air de survivre auprès des développeurs Front (que ce soit pour des outils à la webpack, browserify, babel, etc. ou pour avoir le même code Angular/React/Vue qui tourne côté client et côté serveur).
J'ai volontairement pas parlé du front parce que le sujet est très différent.
Non, il dit que JavaScript a fait des progrès, notamment avec le mot clef async, mais que le modèle du JavaScript reste inférieur pour les serveurs à celui de Go.
Je n'ai probablement pas lu avec assez d'attention je n'ai pas trouvé ce passage.
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 4.
Là tu décris le paterne reactor. C'est une façon de faire de l'évènementiel. On doit pouvoir dire qu'il s'agit de tout ce qui est réactif.
Il y a un tas de façons de gérer ça donc à part dire que c'est de la programmation parallèle, je ne vois pas bien quoi en dire de plus.
Je n'ai pas réussi à trouver l'architecture interne de haproxy ou de sozu [...] je viens de trouver une conférence d'un développeur de sozu. Je te l'ai mis au timecode qui parle de ça, ils font de l'eventloop monothread. Pour ceux qui ne connaissent pas sozu est un reverse proxy sorti l'an dernier (et open source) dont l'objectif est la performance et la capacité à n'avoir aucune downtime y compris lors de ses mises à jour et des changements de configuration. Ils l'ont écris en rust et sont d'abord aller voir ce qu'il y avait sur le marché. Je pense qu'on peut dire qu'ils ont une bonne vision de l'état de l'art du domaine (et au passage il explique que haproxy (comme nginx) est aussi une eventloop monothread).
Je connais mal les green threads comment ils se comportent par rapport aux contexte switch ? Je veux dire :
Tu aurais un exemple de service qui traite un paquet de requêtes en go par exemple ? J'aimerais bien regarder le modèle de threading utilisé.
J'ai volontairement pas parlé du front parce que le sujet est très différent.
Je n'ai probablement pas lu avec assez d'attention je n'ai pas trouvé ce passage.