On Thursday, 12 May 2016 at 14:02:30 UTC, Dsby wrote:
https://github.com/putao-dev/collie
Thank you very much for this library I wasn't aware of.
I see it's using the Reactor pattern (select/kevent/epoll of
Posix) by opposition to the Proactor pattern (IOCP on Windows)
[D. Schmidt et al, Pattern Oriented Software Architecture, Volume
2. Wiley, 2000].
In the Proactor pattern you pass a function and its parameters
(e.g. buffer) to be executed asynchronously. In the Reactor
pattern the user is notified when there is data to read.
The Reactor pattern is superior in many ways to the Proactor
pattern (IOCP):
- There is no need to preallocate a buffer for all input channels
that can stay idle for a long time. This doesn't scale well to
million connections.
- There is no risk to pass a parameter (e.g. array) on the stack
or destroyed before the function execution.
- It is possible to read into (or write data from) a transient
storage on the stack (e.g. array or a struct) and benefit from
RAII and less GC load.
Unfortunately Windows only provide the slow select() operation.
User are advised to use the faster IOCP which I guess is there
mainly for historical reasons.
So the first question to ask when designing an async IO system is
if we go for a Reactor system or a Proactor system.
Nearly all async IO system (except libev) adopted the Proactor
pattern to be compatible with Windows and its IOCP.
My feeling is that if we want to provide a simple, robust and
scalable API, the Reactor pattern should be favored.
