事件驱动模型与反应堆模式有什么区别？ [英] What is the difference between event driven model and reactor pattern?
问题描述
从维基百科反应堆模式文章：
反应堆设计模式是一种事件处理模式，用于处理由一个或多个输入同时发送到服务处理程序的服务请求。
它命名了几个例子，例如 nodejs ， twisted ， eventmachine
如何区分这些框架二？或者它们是一样的？
反应堆模式比事件驱动编程更具体。它是一种在执行事件驱动编程时使用的具体实现技术。但是，这个术语在典型的对话中并没有很准确的使用，所以你应该小心使用它，并期待你的听众理解你，你应该小心，当你使用它来解释这个术语。
查看反应堆模式的一种方法是考虑与非阻塞操作的概念密切相关。当某些操作可以完成而不阻塞时，反应堆发出通知。例如，可以使用 select（2）来实现使用标准BSD套接字API读取和写入套接字的反应器模式（ recv 2）， send（2）等）。例如， c> select 会告诉你什么时候可以立即从套接字接收字节，因为字节存在于该套接字的内核接收缓冲区中。
$ b
在考虑这些想法时，您可能需要考虑的另一个模式是 proactor 模式。与反应器模式相反，原型模式的操作开始，无论它们是否可以立即完成，它们执行异步，然后安排提交有关其完成的通知。
Windows I / O完成端口（IOCP）API是可以看到 proactor 模式的一个示例。当使用IOCP在套接字上执行发送时，发送操作将被启动，而不管该套接字的内核发送缓冲区是否有任何空间。发送操作继续（在另一个线程中，也许是内核中的一个线程），而 WSASend 调用立即完成。当send 实际完成（仅意味着发送的字节已被复制到该套接字的内核发送缓冲区）时，提供给 WSASend 调用被调用（在应用程序的新线程中）。
这种启动操作的方法，然后在完成后被通知是核心思想异步操作。将其与无阻塞操作进行比较，等待操作在尝试执行操作之前立即完成。
任何一种方法可用于事件驱动编程。使用反应堆模式，程序等待（例如）可读取的套接字的事件，然后从中读取。使用proactor模式，程序代替等待套接字读取完成的事件。
严格地说，Twisted滥用术语反应器。基于 select（2）（ twisted.internet.selectreactor ）的Twisted反应器使用非阻塞I / O，这是非常反应堆的。然而，它暴露于应用程序代码的接口是异步的，使得它更像是proactor。 Twisted还有一个基于IOCP的反应堆。该反应堆暴露了同样面向异构应用程序的API ，使用类似于proactor的IOCP API。这种混合方法在平台上的细节不同，使得反应堆和推进者都不是特别准确的，但是由于 twisted.internet.reactor 基本上完全是异步的，而不是非阻塞， proactor 可能是更好的选择。
From the wikipedia Reactor Pattern article:
The reactor design pattern is an event handling pattern for handling service requests delivered concurrently to a service handler by one or more inputs.
It named a few examples, e.g. nodejs, twisted, eventmachine
But what I understand that above is popular event driven framework, so make them also a reactor pattern framework?
How to differentiate between these two? Or they are the same?
The reactor pattern is more specific than "event driven programming". It is a specific implementation technique used when doing event driven programming. However, the term is not used with much accuracy in typical conversation, so you should be careful about using it and expecting your audience to understand you, and you should be careful in how you interpret the term when you encounter its use.
One way to look at the reactor pattern is to consider it closely related to the idea of "non-blocking" operations. The reactor sends out notifications when certain operations can be completed without blocking. For example, select(2) can be used to implement the reactor pattern for reading from and writing to sockets using the standard BSD socket APIs (recv(2), send(2), etc). select will tell you when you can receive bytes from a socket instantly - because the bytes are present in the kernel receiver buffer for that socket, for example.
Another pattern you might want to consider while thinking about these ideas is the proactor pattern. In contrast to the reactor pattern, the proactor pattern has operations start regardless of whether they can finish immediately or not, has them performed asynchronously, and then arranges to deliver notification about their completion.
The Windows I/O Completion Ports (IOCP) API is one example where the proactor pattern can be seen. When performing a send on a socket with IOCP, the send operation is started regardless of whether there is any room in the kernel send buffer for that socket. The send operation continues (in another thread, perhaps a thread in the kernel) while the WSASend call completes immediately. When the send actually completes (meaning only that the bytes being sent have been copied into the kernel send buffer for that socket), a callback function supplied to the WSASend call is invoked (in a new thread in the application).
This approach of starting operations and then being notified when they are complete is central to the idea of asynchronous operations. Compare it to non-blocking operations where you wait until an operation can complete immediately before attempting to perform it.
Either approach can be used for event driven programming. Using the reactor pattern, a program waits for the event of (for example) a socket being readable and then reads from it. Using the proactor pattern, the program instead waits for the event of a socket read completing.
Strictly speaking, Twisted misuses the term reactor. The Twisted reactor which is based on select(2) (twisted.internet.selectreactor) is implemented using non-blocking I/O, which is very reactor-like. However, the interface it exposes to application code is asynchronous, making it more proactor-like. Twisted also has a reactor based on IOCP. This reactor exposes the same asynchronous application-facing API and uses the proactor-like IOCP APIs. This hybrid approach, varying from platform to platform in its details, makes neither the term "reactor" nor "proactor" particularly accurate, but since the API exposed by twisted.internet.reactor is basically entirely asynchronous instead of non-blocking, proactor would probably have been a better choice of name.
这篇关于事件驱动模型与反应堆模式有什么区别？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
