> If this can be called from multiple threads then something has to ensure the eglMakeCurrent
> is called from the right threads (and held for the duration of GL usage), right? So if
> something is doing this then the lock guard is not necessary, if nothing else is handling
> it then its not quite enough....
Not sure I follow, but let me try to explain the reason we need this. If two GL contexts are shared then objects in them live in the same "namespace". Creation of objects in this shared namespace is not thread-safe. So, imagine:
Now if T1 and T2 run concurrently and call glCreateProgram() we have a potential race. What happened in our case was that both T1:glCreateProgram() and T2:glCreateProgram() occasionally returned the same program id, messing things up.
> If this can be called from multiple threads then something has to ensure the eglMakeCurrent
> is called from the right threads (and held for the duration of GL usage), right? So if
> something is doing this then the lock guard is not necessary, if nothing else is handling
> it then its not quite enough....
Not sure I follow, but let me try to explain the reason we need this. If two GL contexts are shared then objects in them live in the same "namespace". Creation of objects in this shared namespace is not thread-safe. So, imagine:
C1: EGL context 1
C2: EGL context 2 shared with context 1
T1: MakeCurrent(C1)
T2: MakeCurrent(C2)
Now if T1 and T2 run concurrently and call glCreateProgram() we have a potential race. What happened in our case was that both T1:glCreateProg ram() and T2:glCreateProg ram() occasionally returned the same program id, messing things up.