Async or event library

chmike via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon May 9 02:14:31 PDT 2016


It seam that the scope of the event loop we are talking should be 
clarified to avoid confusions.

There is the GUI event loop which is generally single threaded 
for efficient access to the data structure representing the GUI 
content. Single thread also simplifies synchronization and make 
deadlocks impossible. GUI events incoming rates are generally 
slow because it is human driven. So a single threaded GUI event 
loop is a very reasonable choice.

The other event loop is for IO and timers. In this case the event 
rate can be very high and the speed is critical. This is where 
multithreading can play a useful role and the topic I am 
interested with.

On unix the OS provides a fast select (epoll, kevent) which tells 
the user on which fd an event occurred. epoll doesn't cover 
asynchronous file operations and timer events.
On Windows the OS provides IOCP which support queued operations 
and the user is notified of the completion.

The boost asio lib adopted the IOCP model. Users queue 
asynchronous tasks and a callback function that is executed when 
the task is completed. That is also the model of I/O or timer 
event loops (e.g. libev, libuv, libevent).

Unfortunately it seam that we don't have much liberty degree if 
we want an API that can work on Windows and unix. But the unix 
model can be more efficient.
Here is a blog post reporting that the author could implement a 
more efficient system than libuv by using epoll directly 
http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html.



More information about the Digitalmars-d-learn mailing list