On Monday, 9 May 2016 at 09:14:31 UTC, chmike wrote:
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.
Have you looked at http://vibed.org? It is the most successful D
library for async IO and it has several backends (some C and some
D). It also provides a high-level web framework functionality on
top, but it is optional and you can freely use only the low-level
stuff.
See also:
http://code.dlang.org/search?q=event
http://code.dlang.org/search?q=async
