As a result, killing glthreads this way almost always leaves X hung, trying to get the lock, waiting for a process which is already dead.
The basic scenario is like this: --------------------------------
parent creates 2 contexts (opens one? drm fd)
parent spawns 2 threads
threads render & grab lock
--> interrupt (while lock is held by child-1)
parent/child-2 dies -- release method called -- pid check to release lock fails
child-1 - release method not called -- lock is never released
==> Actually these may be in the wrong order - perhaps the release() method is only called when the last thread with that fd open is killed... The effect seems to be the same, though.
------------------------------------
In other words, the kernel is never being notified that the pid holding the lock is dying, so it never releases the lock. This is a consequence (I think) of the fact that the client code opens the fd *only once*, and shares it between pids, the locking code is strictly based around pids but relies on the fd release() method for cleanup...
Partly the problem can be seen in this:
[EMAIL PROTECTED] root]# cat /proc/modules radeon 111960 2
despite there being 3 (or 4) users of the module: X, child-1, child-2, parent.
Anyone have any ideas?
Keith
------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel