Could non-rendering functions be made thread-safe?

dev
1

With vsync enabled, glfwSwapBuffers blocks. To work around it, I created another thread for logic, while the main one did drawing only. Basically, main thread loop did this:

  1. Lock mutex.
  2. Draw.
  3. Unlock mutex.
  4. Call glfwSwapBuffers.

The secondary thread loop was doing the following at much faster rate (100 times per second):

  1. Lock mutex.
  2. Do logic. This involves a call to glfwPollEvents and other non-rendering glfw functions.
  3. Unlock mutex.

The problem is that I looked at the documentation and it says that glfwPollEvents could only be used from the main thread, so I should move it to the the main thread (which is drawing and is tied to screen refresh rate). So this essentially ties my logic code (which runs at arbitrary rate) with drawing code (which is tied to screen refresh rate because glfwSwapBuffers blocks with vsync enabled).

Any way to work around this?

2

As you state glfwPollEvents needs to be called from the main thread. See this post on Multithreading GLFW for why.

However you can put the rendering on another thread (make sure to make the context current on that thread).

1 Like
3

Seconded; I would put event processing on the main thread and rendering on the secondary. If you absolutely need to process key presses etc off the main thread, you can implement a queue of your own that passes the relevant events from main to secondary.

1 Like
4

Thank you for the link. I think I understand the situation now.