On Sat, 22 Feb 2003 15:38:40 -0700
Keith Whitwell <[EMAIL PROTECTED]> wrote:
> 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?
No idea, just a comment. This reminded me of the famous X hangs when
flightgear exits. Recently I read in some posts on the plib-users
mailing list that flightgear is multi-threaded, too. The situation is
somewhat different, though. There is only one context and AFAIK only one
thread uses OpenGL. But if both threads share the drm fd then the
release method may be called with the wrong pid (the one not holding the
lock) as well.
>
> Keith
>
Felix
__\|/__ ___ ___ ___
__Tschüß_______\_6 6_/___/__ \___/__ \___/___\___You can do anything,___
_____Felix_______\Ä/\ \_____\ \_____\ \______U___just not everything____
[EMAIL PROTECTED] >o<__/ \___/ \___/ at the same time!
-------------------------------------------------------
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
