Threading compatibility

nobody wrote on Friday, June 04, 2004:

I am looking to port a GLUT based application to GLFW.  In section 8.6 of the UsersGuide.pdf It states "The current release of GLFWis not 100% thread safe. In other words, most GLFW functions may cause conflicts and undefined behaviour if they are called from different threads. "
This applications is heavily dependent upon the use of pthreads.  Will using GLFW be a practical option or should I look for another toolkit that better supports threads?

anonymous wrote on Sunday, June 06, 2004:

I also have questions about threading compatibility. I recently added threading to my program, but I had to take it out because my graphics stopped working. Do the calls to openGL functions like glBegin and glVertex3f have to be called in the same thread as the window was created in? Also, I thought it might be because I had to swap buffers in the same thread, so I moved glfwSwapBuffers() from my main thread to my drawing thread, and my callback functions stopped working.

marcus256 wrote on Thursday, June 10, 2004:

You should be able to use GLFW without problems, if you know what you are doing. The simplest rule is: only call GLFW functions from one thread (the same thread from which you called glfwInit). You can propagate information and control to other threads with custom mutex/condition variable based communication.

Even when/if GLFW bocomes 100% thread safe, you need to consider the fact that GLFW window contexts are per thread only, as are OpenGL contexts.

marcus256 wrote on Thursday, June 10, 2004:

glfwOpenWindow creates an OpenGL rendering context, which is bound to the same thread as called the function (meaning that all gl functions need to be called from that thread). Furthermore GLFW window calls and callbacks should be made from the same thread.

In addition you need to make sure that YOUR application is thread safe (see chapter 8 in the Users Guide).

nobody wrote on Saturday, June 19, 2004:


I was wondering if there is any way using GLFW to separate the event handling from the drawing using threads.

Essentially what I would like to do, is a thread that would take care of all the events (keys and mouse) and another that does the rendering (calls to openGL and swapbuffers).

I was initially motivated to try using GLFW because of the glfwPollEvents() call that allows me to define when I want to process events (unlike GLUT) without losing them in between checks. So my update thread could handle all pending events, given these update the scene while no more events can affect it, and loop.

The update thread always has stuff it can do, and thus might be able to run through loops independantly of the renderer (most probably at a far higher rate).

Thanks for any info
Tony Bernardin

marcus256 wrote on Wednesday, July 07, 2004:

You can not do that. Not now, and not in future versions of GLFW. Many OS:es couple window contexts to threads very tightly, so that you can only process window events from the thread that owns the window (which usually is the same thread that owns the GL context - although some OSes allow you to use a rendering context from different threads).

Anyway, it is seldom necessary to split the event processing and GL rendering into different threads. Events are queued until they are dealt with, and a program can usually not act on new events during GL rendering anyway - only in between GL frames.