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.
