Désolé, je ne comprends toujours pas. Ça veut dire quoi « être réactif » ?
C'est le mot à la mode pour dire qu'on utilise un pattern reactor (AM*H*A).
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.
Pour moi une distinction importante consiste dans le fait de recevoir un évènement et que cet évènement contient toute l'information utile à mettre en rapport avec le fait de tout envoyer dans le contexte d'un fil d'exécution. Quand tu spaw un thread par requête et que ton framework te positionne dans le contexte de ton thread toute l'information utile (la requête, l'authentification, etc), tu peux difficilement dire que tu es évènementiel. C'est typiquement ce que fais Spring par exemple. Il utilise intensivement le thread local storage.
Merci pour le lien. De ce que j'ai l'impression il remplace les appels asynchrones par des appels synchrones, mais qui indique qu'il faut les préempter et c'est la différence avec CFS. Par contre je ne vois pas comment ça pourrait bien se passer en terme de cache. Le context switch est drastiquement plus léger, mais il est toujours là, on invalide forcément tous les caches, etc.
Merci pour les exemples. J'ai l'impression que les green threads sont là pour être plus simple qu'un monde juste asynchrone. Mais je n'arrive pas à voir cela comme véritablement plus efficace que d'autres solutions pour pallier aux callback hell.
[^] # Re: Retour vers le passé
Posté par barmic . En réponse au journal Des vieilles bases d'unix à la hype reactive actuelle. Évalué à 2.
C'est le mot à la mode pour dire qu'on utilise un pattern reactor (AM*H*A).
Pour moi une distinction importante consiste dans le fait de recevoir un évènement et que cet évènement contient toute l'information utile à mettre en rapport avec le fait de tout envoyer dans le contexte d'un fil d'exécution. Quand tu spaw un thread par requête et que ton framework te positionne dans le contexte de ton thread toute l'information utile (la requête, l'authentification, etc), tu peux difficilement dire que tu es évènementiel. C'est typiquement ce que fais Spring par exemple. Il utilise intensivement le thread local storage.
Merci pour le lien. De ce que j'ai l'impression il remplace les appels asynchrones par des appels synchrones, mais qui indique qu'il faut les préempter et c'est la différence avec CFS. Par contre je ne vois pas comment ça pourrait bien se passer en terme de cache. Le context switch est drastiquement plus léger, mais il est toujours là, on invalide forcément tous les caches, etc.
Merci pour les exemples. J'ai l'impression que les green threads sont là pour être plus simple qu'un monde juste asynchrone. Mais je n'arrive pas à voir cela comme véritablement plus efficace que d'autres solutions pour pallier aux callback hell.