pdid
pdid

Reputation: 347

glfwInit() from non-main thread

The glfwInit() JavaDoc for LWJGL 3 states:

This function must only be called from the main thread.

However, I've tested this on a acer machine running windows 10, and I've found that it does not matter which thread glfwInit() is called on, as long as it is the same thread as any other glfw calls.

Is the documentation wrong, or does it only apply to certain machines or OSs?

Upvotes: 3

Views: 1211

Answers (1)

vallentin
vallentin

Reputation: 26207

I've found that it does not matter which thread glfwInit() is called on

First of all. Just because something seems to work, doesn't mean it will continue to work. In other words, some specific event might end up crashing your application which you haven't tested for yet.

This function must only be called from the main thread.

The important thing here is that the GLFW documentation never specifies what is meant by the "main thread".

Quoting GLFW's developer and maintainer Camilla Löwy / elmindreda.

Cocoa has a single event queue that may only be accessed from the main thread, and the same goes for most window operations. Win32 has one event queue per thread and windows are tied to the queue of the thread that created them. X11 has a single queue and event processing and window operations may be done from any thread. The limitation imposed by GLFW is to ensure that programs are portable. This limitation is not enforced, i.e. the library does not try to prevent you from shooting yourself in the foot. If loading or rendering blocks your program, put it in another thread. Everything you need to render and swap buffers is thread-safe on all platforms for this reason.

The limitation imposed by GLFW is to ensure that programs are portable. This limitation is not enforced, i.e. the library does not try to prevent you from shooting yourself in the foot.

So in short. Cocoa won't be happy. However on Windows given that the window and the OpenGL context is created on the same thread, then there shouldn't be any problems.

But in the end it's better to play by the rules to ensure that programs are portable.

Upvotes: 6

Related Questions