Quelle est la différence entre le modèle événementiel et le modèle de réacteur?

Question

Extrait de l'article de wikipedia Reactor Pattern :

 The reactor design pattern is an event handling pattern for handling service
requests delivered concurrently to a service handler by one or more inputs
 

Elle a cité quelques exemples, par exemple nodejs , twisted , eventmachine

Mais ce que je comprends que ci-dessus est un cadre populaire basé sur les événements, alors faites-en aussi un cadre de modèle de réacteur?

Comment différencier ces deux? Ou sont-ils les mêmes?

Answer 1

Le réacteur est plus spécifique que "la programmation événementielle". C'est une mise en œuvre spécifique de la technique utilisée quand on fait de la programmation événementielle. Cependant, le terme n'est pas utilisé avec beaucoup de précision typique de la conversation, donc vous devez être prudent quant à l'utilisation et attendons de votre auditoire à comprendre vous, et vous devez être prudent dans la manière dont on interprète le terme lorsque vous vous heurtez à son utilisation.

Une manière de regarder le réacteur modèle est de considérer qu'il étroitement liée à l'idée de "non bloquant". Le réacteur envoie des notifications lors de certaines opérations peuvent être effectuées sans blocage. Par exemple, select(2) peut être utilisé pour mettre en œuvre le modèle de réacteur pour la lecture et l'écriture sur les sockets en utilisant le standard de BSD socket Api (recv(2), send(2), etc). select vous dira quand vous pouvez recevoir des octets à partir d'une prise instantanément, parce que les octets sont présents dans le noyau récepteur de la mémoire tampon pour ce socket, par exemple.

Un autre motif que vous pourriez vouloir prendre en compte lors de la réflexion sur ces idées est la proactor modèle. En revanche pour le réacteur modèle, la proactor motif est opérations de démarrer indépendamment de savoir si elles peuvent se terminer immédiatement ou non, a joué de manière asynchrone, et organise pour fournir une notification sur leur réalisation.

Le Windows I/O Ports d'Achèvement (IOCP) de l'API est un exemple où le proactor modèle peut être vu. Lors de l'exécution d'un envoi sur un support avec IOCP, l'opération d'envoi est lancé, indépendamment de savoir si il y a n'importe quelle pièce dans le noyau du tampon d'envoi de ce socket. L'opération d'envoi continue (dans un autre fil, peut-être un fil dans le noyau), tandis que l' WSASend appel se termine immédiatement. Lorsque l'envoyer en réalité complète (ce qui signifie seulement que les octets envoyés ont été copiées dans le noyau du tampon d'envoi de ce socket), une fonction de callback fournie à l' WSASend appel est appelé (dans un nouveau thread dans l'application).

Cette approche de commencer les opérations, puis d'en être informés quand ils sont au complet est au centre de l'idée de l' asynchrone opérations. La comparer à la non-blocage des opérations où vous attendez jusqu'à ce qu'une opération peut s'effectuer immédiatement avant de tenter de le réaliser.

Les deux approches peuvent être utilisées pour la programmation événementielle. En utilisant le modèle de réacteur, un programme attend le cas de (par exemple) un socket est lisible et lit ensuite. À l'aide de la proactor modèle, le programme attend le cas d'une prise en lecture à la fin.

Strictement parlant, Tordu abuse du terme réacteur. La torsion du réacteur, qui est basé sur select(2) (twisted.internet.selectreactor) est mis en œuvre à l'aide de non-blocage I/O, ce qui est très réacteur. Cependant, l'interface, il expose au code de l'application est asynchrone, le rendant plus proactor. Twisted dispose également d'un réacteur basé sur IOCP. Ce réacteur expose la même application asynchrone-API et utilise le proactor-comme IOCP Api. Cette approche hybride, variant de plate-forme à plate-forme dans ses détails, ne fait ni le terme "réacteur", ni "proactor" particulièrement précis, mais depuis l'API exposées par l' twisted.internet.reactor est fondamentalement totalement asynchrone au lieu de non-blocage, proactor aurait sans doute été un meilleur choix de nom.