Simple WinAPI Event manager implementation

Question

Trying to learn windows internals and made my first work with Events and Threads. What do you think about my code? Any advice?

#include <windows.h>
#include <iostream>
#include <vector>

enum class EventType : UINT8
{
    EVENT_TYPE_1,
    EVENT_TYPE_N
};
using EventFnc = void (*)(void);

struct Event
{
    EventType type;
    EventFnc on_event_fnc;
};

class Events
{
private:
    std::vector<Event> _events;
    std::vector<HANDLE> _handles;
    HANDLE events_changed_evt{INVALID_HANDLE_VALUE};
    HANDLE events_dtor_evt{INVALID_HANDLE_VALUE};
    HANDLE wait_event_thread_hwnd{INVALID_HANDLE_VALUE};
    DWORD wait_event_thread_id{0};

private:
    static DWORD WINAPI _WaitEventThreadStatic(LPVOID param)
    {
        return ((Events *)param)->_WaitEventProc();
    }

    DWORD WINAPI _WaitEventProc()
    {
        while (true)
        {
            DWORD event_index = WaitForMultipleObjects(_handles.size(), _handles.data(), FALSE, INFINITE);
            if (event_index == WAIT_FAILED)
            {
                throw std::runtime_error("WaitForMultipleObjects failed");
            }
            event_index -= WAIT_OBJECT_0;
            switch (event_index)
            {
            case 0:
                /* events_changed_evt */
                continue;
            case 1:
                /* events_dtor_evt */
                return 0;
            default:
                /* user events */
                SIZE_T idx = event_index - (_handles.size() - _events.size());
            _events[idx].on_event_fnc();
                break;
            }
        }
        return 0;
    }

public:
    Events()
    {
        events_dtor_evt = ::CreateEventW(NULL, FALSE, FALSE, NULL);
        if (events_dtor_evt == NULL)
        {
            throw std::runtime_error("Failed to create event");
        }
        events_changed_evt = ::CreateEventW(NULL, FALSE, FALSE, NULL);
        if (events_changed_evt == NULL)
        {
            throw std::runtime_error("Failed to create event");
        }
        wait_event_thread_hwnd = ::CreateThread(NULL, 0, _WaitEventThreadStatic, (LPVOID)this, CREATE_SUSPENDED, &wait_event_thread_id);
        if (wait_event_thread_hwnd == NULL)
        {
            throw std::runtime_error("Failed to create thread");
        }
        _handles.push_back(events_changed_evt);
        _handles.push_back(events_dtor_evt);
        if (::ResumeThread(wait_event_thread_hwnd) == (DWORD)-1)
        {
            throw std::runtime_error("Failed to resume thread");
        }
    }
    ~Events()
    {
        ::SetEvent(events_dtor_evt);
        for (const auto hwnd : _handles)
        {
            ::CloseHandle(hwnd);
        }
        ::CloseHandle(wait_event_thread_hwnd);
    }

    Events(const Event &) = delete;
    Events(Event &&) = delete;
    Events &operator=(const Event &) = delete;
    Events &operator=(Event &&) = delete;

public:
    SIZE_T AddEvent(const Event &event)
    {
        HANDLE hwnd = ::CreateEventW(NULL, FALSE, FALSE, NULL);
        if (hwnd == NULL)
        {
            throw std::runtime_error("Failed to create event");
        }
        _events.push_back(event);
        _handles.push_back(hwnd);
        ::SetEvent(events_changed_evt);
        return _handles.size()-1;
    }
    bool TriggerEvent(SIZE_T event_id) const
    {
        if (event_id < _handles.size())
        {
            ::SetEvent(_handles[event_id]);
            return true;
        }
        return false;
    }
    // bool TriggerEvent(EventType event_type) const
    // {
    //     bool res{false};
    //     for (const auto &event : _events)
    //     {
    //         if (event.type == event_type)
    //         {
    //             ::SetEvent(_handles[event.id]);
    //             res = true;
    //         }
    //     }
    //     return res;
    // }
};

void OnEvent(void){
    std::cout << "Event 1";
}

int APIENTRY main()
{
    Events evts;
    SIZE_T id = evts.AddEvent({EventType::EVENT_TYPE_1,&OnEvent});
    
    evts.TriggerEvent(id);
    while(true);
    return 0;
}

What's this code actually for - how would you call it what's an example use case? — Greedo
– Greedo, Commented Apr 28 at 10:03
code for learning how works SetEvent and how to catch them. What will be better? create thread for each Event with WaitForSingleObject or to make as i made (like epoll)? — vansergh
– vansergh, Commented Apr 28 at 10:41

G. Sliepen · Accepted Answer · 2025-08-08 13:38:04Z

Use standard C++ where possible

The Windows API was started long ago for C, when things were not as standardized as they were now. Today we are in a much better situation, and I recommend you make use of it. A lot of Windowsisms can be removed:

UINT8, DWORD, SIZE_T, LPVOID: use std::uint8_t, std::uint32_t, std::size_t and void*.
WINAPI: only use this for functions that are called by outside code. I don't think you need it for _WaitEventProc().
CreateThread(): use std::thread or std::jthread instead if possible.
EventFnc: use std::function<void()> instead.
You can use more auto to avoid having to specify types.

Thread safety issues

Your code uses threads, so you have to make sure it is thread-safe. If AddEvent() is called while _WaitEventProc() is handling an event, things can go very wrong.

At a first glance, the solution seems to be to use a std::mutex to guard access to _handles and _events. However, that quickly results in a problem: since you pass _handles.size() and _handles.data() to WaitForMultipleObjects(), you have to lock the mutex while that system call is waiting. This will cause AddEvent() to block however, as that also needs to lock the mutex to be able to add the event. So you can't use this approach.

You could think about making a local copy of _handles and _events in _waitEventProc() before calling WaitForMultipleObjects(), or perhaps some more fancy scheme where you have a vector _handles_to_add and _events_to_add, which _waitEventProc() will then move over to _handles and _events.

Another option is to reserve() size for the maximum number of events you'll even wait on (equal to MAXIMUM_WAIT_OBJECTS perhaps?). You can then safely add events, but you still cannot safely remove events. Also, you still need to use a mutex to lock when reading _handles.size() before calling WaitForMultipleObjects(), otherwise there is a race condition where the size gets incremented but the element at the last position isn't written yet.

Also consider that you might have multiple threads calling AddEvent(), so make sure that case is handled correctly as well.

Restructure the code

While all the functionality is in place, things are spread around a bit too much. Make use of the fact that you can nest structs and classes. Also make AddEvent take an EventType and a EventFnc separately, so the caller doesn't need to know about Event:

class Events
{
    std::mutex mutex;
    …
public:
    enum class Type: std::uint8_t
    {
        …
    };

    using Function = std::function<void()>;
    …
    std::size_t Add(Type type, Function function)
    {
        auto handle = CreateEventW(nullptr, false, false, nullptr);
        if (handle == nullptr)
        {
            throw std::runtime_error("Failed to create event");
        }

        std::size_t event_id;

        {
            std::lock_guard lock(mutex);
            event_id = _events.size();
            events.emplace_back(type, function);
            handles.emplace_back(handle);
        }

        SetEvent(events_changed_evt);
        return event_id;
    }
    …
};

int main() {
    Events events;

    auto event_id = events.Add(Events::Type::EVENT_TYPE_1, []{
        std::cout << "Event 1\n";
    });

    events.Trigger(event_id);

    std::cin.get();
}

Naming things

Some minor issues with the way you name things:

Avoid unncessary abbreviations:
- Fnc -> Function
- evt -> event
- dtor -> destructor
- hwnd -> handle (especially if it's not a window handle)
Avoid repeating words that are already clear from the context
- EventType -> Type, since it's already part of struct Event (or class Events).
- EventFnc -> Function, same reason.
- AddEvent() -> Add()
- TriggerEvent() -> Trigger()
It's more common to use snake_case for function names, and keep using PascalCase for struct, class and enum names.
Avoid leading underscores in names. Unless you know the rules exactly, use an underscore at the end, or use m_ as the prefix for member variable names. It's also very uncommon to use any prefix or suffix for private function names.

"use m_ as the prefix for local variable names" -- you mean for member variables, right? — uli
– uli, Commented Aug 7 at 20:34

kiner_shah · Accepted Answer · 2025-04-29 07:50:54Z

2

Don't use ALL_CAPS for enumerators.
Run thread sanitizer on the code, it will catch race conditions.
Don't use while (true);. If by chance you miss that semicolon, you get an undefined behavior whose root cause can be difficult to find. Use a block with an empty statement while (true) { ; }. Although the design can be made better (like introducing some method in Events that will block until interrupted by user somehow).

answered Apr 29 at 7:50

kiner_shah

5752 silver badges9 bronze badges

Add a comment |

Stack Exchange Network

Simple WinAPI Event manager implementation

2 Answers 2

Use standard C++ where possible

Thread safety issues

Restructure the code

Naming things

You must log in to answer this question.

Hot Network Questions

Simple WinAPI Event manager implementation

2 Answers 2

Use standard C++ where possible

Thread safety issues

Restructure the code

Naming things

You must log in to answer this question.

Related

Hot Network Questions