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.
Désolé, je ne comprends toujours pas. Ça veut dire quoi « être réactif » ? Qu'est-ce qui est du domaine de la programmation événementielle si ce n'est l'utilisation du patern reactor ? Si la programmation événementielle, c'est réagir à des événements, j'ai l'impression que la définition englobe toutes les implémentations côté serveur, je ne vois pas comment un serveur pourrait ne pas « réagir » à des requêtes réseau.
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.
Merci, je vais regarder ça, ça m'intéresse beaucoup !
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 ?
https://dave.cheney.net/2015/08/08/performance-without-the-event-loop est une introduction aux goroutines de Go de ce point de vue. En gros, chaque goroutine est très légère, on peut facilement en avoir des dizaines de milliers ou plus. Le runtime de Go lance plusieurs threads, un par coeur (en fait, c'est configurable via une variable d'environnement mais c'est la valeur par défaut) qui vont servir à exécuter ces goroutines. Et il lance également des threads pour les opérations bloquantes d'I/O. Il fait ensuite en sorte que chaque thread d'exécution exécute une goroutine pendant un laps de temps assez court, puis passe à une autre. Si une goroutine est en attente, que ce soit parce qu'elle va faire une opération d'I/O ou qu'elle attende d'envoyer ou recevoir une valeur sur un channel, elle n'est plus éligible à être exécuté sur ces threads.
comment le runtime d'un langage est plus à même de faire des choix que CFS ?
Je ne pense pas que le runtime du langage fasse de meilleurs choix que CFS, par contre, il peut faire ce choix plus rapidement. Et un autre avantage est qu'une goroutine (ou plus généralement un green thread) coûte beaucoup moins cher en RAM. Le problème C10K était notamment hostile pour les programmes qui utilisaient un thread par connexion car la RAM était rapidement saturée.
comment se comporte le contexte swicth ? c'est juste qu'on reste dans l'espace utilisateur ?
Oui, on reste dans l'espace utilisateur. En général, les green threads marche en mode coopératif : ce n'est pas un scheduler qui vient interrompre l'exécution, mais le green thread qui vérifie régulièrement s'il doit laisser la main à un autre green thread (par exemple, lors du lancement du garbage collector). Enfin, les opérations à faire pour passer d'un green thread à un autre sont, il me semble, moins couteuses que pour passer d'un thread à un autre.
comment cela se passe par rapport aux caches CPU ?
Je ne sais pas.
Tu aurais un exemple de service qui traite un paquet de requêtes en go par exemple ?
[^] # Re: Retour vers le passé
Posté par Bruno Michel (site web personnel) . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 5.
Désolé, je ne comprends toujours pas. Ça veut dire quoi « être réactif » ? Qu'est-ce qui est du domaine de la programmation événementielle si ce n'est l'utilisation du patern reactor ? Si la programmation événementielle, c'est réagir à des événements, j'ai l'impression que la définition englobe toutes les implémentations côté serveur, je ne vois pas comment un serveur pourrait ne pas « réagir » à des requêtes réseau.
Merci, je vais regarder ça, ça m'intéresse beaucoup !
C'est de moins en moins vrai pour le côté mono-thread. Le multithread arrive pour haproxy et il me semble que nginx a des pools de threads de nos jours.
https://dave.cheney.net/2015/08/08/performance-without-the-event-loop est une introduction aux goroutines de Go de ce point de vue. En gros, chaque goroutine est très légère, on peut facilement en avoir des dizaines de milliers ou plus. Le runtime de Go lance plusieurs threads, un par coeur (en fait, c'est configurable via une variable d'environnement mais c'est la valeur par défaut) qui vont servir à exécuter ces goroutines. Et il lance également des threads pour les opérations bloquantes d'I/O. Il fait ensuite en sorte que chaque thread d'exécution exécute une goroutine pendant un laps de temps assez court, puis passe à une autre. Si une goroutine est en attente, que ce soit parce qu'elle va faire une opération d'I/O ou qu'elle attende d'envoyer ou recevoir une valeur sur un channel, elle n'est plus éligible à être exécuté sur ces threads.
Je ne pense pas que le runtime du langage fasse de meilleurs choix que CFS, par contre, il peut faire ce choix plus rapidement. Et un autre avantage est qu'une goroutine (ou plus généralement un green thread) coûte beaucoup moins cher en RAM. Le problème C10K était notamment hostile pour les programmes qui utilisaient un thread par connexion car la RAM était rapidement saturée.
Oui, on reste dans l'espace utilisateur. En général, les green threads marche en mode coopératif : ce n'est pas un scheduler qui vient interrompre l'exécution, mais le green thread qui vérifie régulièrement s'il doit laisser la main à un autre green thread (par exemple, lors du lancement du garbage collector). Enfin, les opérations à faire pour passer d'un green thread à un autre sont, il me semble, moins couteuses que pour passer d'un thread à un autre.
Je ne sais pas.