Async or event library

chmike via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon May 16 10:08:32 PDT 2016


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.





More information about the Digitalmars-d-learn mailing list