Yes, that’s a great explanation!
So, my take away is to:
- make all GLFW/Event calls on a dedicated thread.
- make another dedicated thread for GL calls [optionally.]
So, in my case, I will have to delegate to thread 1 when I need to create a window & set callbacks, as well as any window operations. (EDIT: however, this could be as trivial as posting an empty event with glfwPostEmptyEvent, so no need for extra signaling/polling.) This is because my program may request windows at any time, from any thread, as opposed to opening them at startup[*]. Then thread 1 may opt to delegate to thread 2 for rendering.
[*]The one thing that’s still a question is whether I need at least one window alive at all times while thread 1 is spinning. I’d prefer not to have to shutdown/restart thread 1 every time all windows have been closed, and then a new one is requested. I’d prefer not to create a dummy window/window pool during init either.
I thought I read in the docs that a window was required before event polling, but maybe I was mistaken, or that was outdated. (Sorry for the confusion.) I was able to find this:
GLFW needs to communicate regularly with the window system both in order to receive events and to show that the application hasn’t locked up. Event processing must be done regularly while you have any windows and is normally done each frame after buffer swapping. Even when you have no windows, event polling needs to be done in order to receive monitor connection events.
So it looks like event polling can go ahead and spin up, (and as long as glfw/events are in that thread, it’s supported cross-platform.) Did I understand that correctly?
Thanks. I apologize for the confusion.