How Would You Implement a Basic Event-Loop

How would you implement a basic event-loop?

I used to wonder a lot about the same!

A GUI main loop looks like this, in pseudo-code:

void App::exec() {
    for(;;) {
        vector<Waitable> waitables;
        waitables.push_back(m_networkSocket);
        waitables.push_back(m_xConnection);
        waitables.push_back(m_globalTimer);
        Waitable* whatHappened = System::waitOnAll(waitables);
        switch(whatHappened) {
            case &m_networkSocket: readAndDispatchNetworkEvent(); break;
            case &m_xConnection: readAndDispatchGuiEvent(); break;
            case &m_globalTimer: readAndDispatchTimerEvent(); break;
        }
    }
}

What is a "Waitable"? Well, it's system dependant. On UNIX it's called a "file descriptor" and "waitOnAll" is the ::select system call. The so-called vector<Waitable> is a ::fd_set on UNIX, and "whatHappened" is actually queried via FD_ISSET. The actual waitable-handles are acquired in various ways, for example m_xConnection can be taken from ::XConnectionNumber(). X11 also provides a high-level, portable API for this -- ::XNextEvent() -- but if you were to use that, you wouldn't be able to wait on several event sources simultaneously.

How does the blocking work? "waitOnAll" is a syscall that tells the OS to put your process on a "sleep list". This means you are not given any CPU time until an event occurs on one of the waitables. This, then, means your process is idle, consuming 0% CPU. When an event occurs, your process will briefly react to it and then return to idle state. GUI apps spend almost all their time idling.

What happens to all the CPU cycles while you're sleeping? Depends. Sometimes another process will have a use for them. If not, your OS will busy-loop the CPU, or put it into temporary low-power mode, etc.

Please ask for further details!

An efficient event loop implementation?

The most common pattern is:

while (WaitForNextEvent()) {
    HandleEvent();
}

With WaitForNextEvent() returning false to indicate there are no more events to process, and, most importantly, being able to perform a blocking wait for the next event.

For instance, the event source might be a file, a socket, the thread's message queue or another waitable object of some kind. In that case, you can guarantee that HandleEvent() only runs if an event is ready, and is triggered very shortly after an event becomes ready.

Implementations for event loop in C/C++ that's nice on the call stack

The initial solutions is fundamentally broken. Event loop looks something like this:

while (q != QUITE) {
  q = wait_for_query();
  handle_query(q);
}

It's as simple as this. Which actually agrees with what you described:

They're an easy concept: Wait for an event, handle event, wait for more events.

In initial code, semantically, handling the event, handle_query(), will never be completed until all future events are also completed, recursively, meaning no event will ever be completed. Which is not what you want.

The detailed might get very complicated, e.g how you get the events? does it blocks or not? how events are dispatched? ... etc.

How to efficiently implement an event loop?

With event objects.

The main thread calls CreateEvent() in its initialisation to create an auto-reset event object.

The main thread then enters an event loop in which it calls MsgWaitForMultipleObjects() repeatedly. (here is an example of a message loop.)

And you generally do need to check for window messages, even if the main thread has no GUI.

In the client thread (the one that creates the sink object) call SetEvent() within the sink method, after any necessary state update. This will wake up the main thread.

And read this and this, if you haven't already.

Basic Event Loop in Python

An event loop is a loop which handles / deals with events.

An event is something that occurs in the system where some code parts might be interested in.

At the beginning, all components register for events, and after that, an init event is fired:

I am just providing raw code here:

listeners = [component1, component2, component3]
eventqueue.add(InitEvent())
while True:
    event = eventqueue.pop()
    for listener in listeners:
        listener.handle_event(event)

How an eventqueue is implemented and what the Event() class hierarchy looks like is left as an exercise for the reader. Take care about using threading.(R)Locks etc. for the .pop() method.

Additionally, you could have separate listener lists for each event type. An event could thus be "fired" by just calling it (or its .fire() method) and have a mechanism to identify all its own and parent's listeners in order to inform them about the event.

In any case, the listeners then can decide on their own what to do with and according to the event.

Simple timer event loop

You are playing in undefined behavior territory. libuv is not thread-safe see the docs here So while running the loop in a thread is ok, creating a timer in another thread while the loop is running is not.

You can still do it by using a uv_async_t handle and a semaphore: uv_async_send is thread-safe, so you would call it from the outside, stop the loop and signal a semaphore. The calling thread would wait until the semaphore is signaled. At this point the loop is stopped, so it's ok to create a new timer and add it.

There is no API to know how much time a timer has left.

If all you need is a loop to control some timers libuv might be overkill. You could use timerfd if you're on Linux, or a hand-built event loop which only does timers on top of select for example.

---

Related Topics