[Mesa-dev] Mesa drivers/GLX and fork

James Jones jajones at nvidia.com
Tue Oct 15 17:55:22 CEST 2013


In case it helps, we have always interpreted the spec as follows:

-Forking duplicates process memory and FDs, including the display 
connection and the GLX context client-side state (and GL server state if 
direct rendering, but not X server state, such as the context XID), as 
messy as that is.

-A context can only be current to one thread of execution at a time

-Therefore, forking with a context current to the forking thread 
produces undefined behavior, since that would result in a context 
current in more than one process at the same time, and therefore more 
than one thread.  We try not to crash, but if the application ever calls 
into GL, GLX, or EGL again from this new thread, results may vary. 
Usually something crashes.

I would like to get some language into the GLX/EGL specs regarding this, 
or at the very least define some sort of expected behavior in the new GL 
ABI.

The driver-created offload thread is certainly another interesting 
wrinkle here.  However, I presume if the application was at least 
required to call some GLX (or EGL) function after the fork to set up a 
current context (As is the case in our interpretation of the spec), that 
would provide a good opportunity to re-initialize any driver state like 
internal threads?

Thanks,
-James

On 10/15/13 3:45 AM, Christian König wrote:
> Hi Marek,
>
> for the past few days I've been working on solving
> https://bugs.freedesktop.org/show_bug.cgi?id=70123.
>
> The basic problem is that compton forks itself into the background after
> initializing the X server connection and GLX context. What happens now
> is that only comptons main thread get's cloned by the fork, but not any
> background thread created by the radeon winsys to offload the command
> submission (that is common and very well known pthread behaviour).
>
> I'm not 100% sure if comptons behaviour is valid or not and so if we
> should try to fix it or not. On the one hand it should be transparent to
> the application that we created another thread to offload some work from
> the main thread, but on on the other hand dublicating the X connection
> and GLX context with fork just screams for problems.
>
> Any idea what the spec(s) say about this?
>
> Thanks,
> Christian.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>

nvpublic


More information about the mesa-dev mailing list