Explication simple pour le «modèle de réacteur» avec ses applications [fermé]

Le modèle de réacteur est expliqué dans wikipedia , et c'est un peu trop abstrait. Pouvez-vous décrire ce modèle de manière plus concrète? Idéalement avec des extraits de code ou des diagrammes de classe de haut niveau décrivant certaines applications du modèle de réacteur.

design-patterns

— Eleco
source

J'ai trouvé que cette question était une excellente réponse - stackoverflow.com/questions/9138294/…

— Ryan Gibbons

Réponses:

Vous voudrez peut-être consulter le document original le décrivant http://www.dre.vanderbilt.edu/~schmidt/PDF/reactor-siemens.pdf

Le modèle de conception Reactor gère les demandes de service qui sont livrées simultanément à une application par un ou plusieurs clients. Chaque service d'une application peut se composer de plusieurs méthodes et est représenté par un gestionnaire d'événements distinct qui est responsable de la distribution des demandes spécifiques au service. La distribution des gestionnaires d'événements est effectuée par un répartiteur d'initiation, qui gère les gestionnaires d'événements enregistrés. Le démultiplexage des demandes de service est effectué par un démultiplexeur d'événements synchrones.

— reese
source

Comme vous le remarquerez en lisant l'article, Douglas Schmidt et.al ont implémenté un framework C ++ hautement efficace et modulaire appelé The Adaptive Communications Environment, où le modèle Reactor joue un rôle central. Le cadre lui-même utilise une pléthore de modèles de conception et mérite d'être examiné pour cela seul. Si vous recherchez un framework portable pour créer des backends C ++ hautement évolutifs, alors ACE vaut la peine d'être examiné.

— user2015735

@reese Link est cassé aujourd'hui homme :(

— Allan Chua

@AllanChua Je pense que je l'ai trouvé - dre.vanderbilt.edu/~schmidt/PDF/Reactor.pdf

— sergeyrar

OP a demandé une explication "simple et concrète", et vous avez proposé quelque chose d'encore plus abstrait que Wikipédia ...

— Zhe

Un réacteur permet de traiter efficacement plusieurs tâches qui bloquent (par exemple en raison des E / S) en utilisant un seul thread. Le réacteur gère un pool de gestionnaires et exécute une boucle d'événements. Lorsqu'il est appelé pour effectuer une tâche, il le lie à un gestionnaire nouveau ou vacant, le rendant actif. La boucle d'événements (1) trouve tous les gestionnaires actifs et débloqués (ou les délègue à une implémentation de répartiteur) (2) exécute chacun de ces gestionnaires trouvés séquentiellement jusqu'à ce qu'ils terminent ou atteignent un point où ils se bloquent. Les gestionnaires terminés deviennent inactifs et vacants pour une réutilisation tandis que les gestionnaires actifs bloqués cèdent, permettant à la boucle d'événements de se poursuivre. (3) Répète à partir de l'étape (1)

— andrew pate
source

Downvote car ce n'est pas correct

— SebNag

L'idée de base est d'effectuer un démultiplexage d'événements synchrones. Les gestionnaires d'événements ne sont appelés que s'ils peuvent s'exécuter de manière non bloquante, par exemple l'ensemble du paquet de données est disponible sur une socket réseau, en attendant qu'un gestionnaire d'événements traite les données. Cela permet d'exécuter le gestionnaire d'événements séquentiellement de manière non bloquante

— SebNag

"le modèle Reactor est responsable du démultiplexage et de la distribution de plusieurs gestionnaires d'événements qui sont déclenchés lorsqu'il est possible de lancer une opération de manière synchrone sans blocage." extrait de l'article lié dans la réponse acceptée

— SebNag

Ce n'est pas vrai du tout. Il y a autant de fils dans un non-réacteur qu'il y en a dans un modèle de réacteur. Au lieu d'une boucle d'événements, vous pouvez avoir un seul thread "pilote" qui n'utilise pas le modèle observateur / écouteur d'événements. Même performance.

— Zombies