The Proactor Vs Reactor Pattern
Asynchronous servers fall into two architectural styles that differ in when the application is notified.
The reactor pattern is built around readiness. The event loop waits until a socket is ready to read or write, then hands control to a handler that performs the actual operation. The application does the IO itself; the kernel only signals that it will not block. Epoll based servers are classic reactors.
The proactor pattern is built around completion. The application asks the kernel to perform the whole operation, such as read this many bytes into this buffer. The kernel does the work and notifies the application only when it is finished, delivering the result directly. Windows IOCP and the newer Linux io uring follow this style.
- Reactor You are told a socket is ready, then you do the read or write.
- Proactor You request an operation, the kernel completes it, then you are handed the result.
- Trade off Reactor is simpler and portable, proactor can reduce copies and system calls but needs deeper kernel support.
Both let one thread drive many connections. The choice shapes the code: readiness handlers versus completion callbacks.
Key idea
A reactor notifies you when a socket is ready and you perform the IO, while a proactor performs the IO for you and notifies you when it completes.