Running into a problem when killing glthreads with Ctrl-C. Normally this would invoke the release() method and clean up buffers, locks etc. Unfortunately this doesn't work so well with threads - the release method is being called only once despite the 3 processes (threads) that are being killed. Unfortunately the drm module makes use of current->pid extensively, so it really expects each thread to invoke a release() call.

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

Reply via email to