On Sun, Aug 1, 2010 at 11:19 PM, Mario Kleiner
<mario.klei...@tuebingen.mpg.de> wrote:
> Think i sent it to the wrong mailing list. Here we go again...
>
> Begin forwarded message:
>
>> From: Mario Kleiner <mario.klei...@tuebingen.mpg.de>
>> Date: July 27, 2010 2:56:04 AM GMT+02:00
>> To: Kristian Hogsberg <k...@bitplanet.net>, xorg-de...@lists.x.org
>> Subject: Bug: Deadlock for multi-threaded glx apps inside
>> __glXInitialize()
>>
>> Hi Kristian
>>
>> Testing with current mesa master, my toolkit deadlocks on the first call
>> to a glX function (glXChooseVisual()).
>>
>> The deadlock was probably introduced by your recent commit:
>>
>> "glx: Use _Xglobal_lock for protecting extension display list"
>>
>> ab434f6b7641a64d30725a9ac24929240362d466
>>
>> The problem is that the _Xglobal_lock is locked twice inside the
>> __glXInitialize() function of mesa/src/glx/glxext.c, once inside
>> __glXInitialize(), and then as part of dri2CreateDisplay() -> ... ->
>> XextFindDisplay. The 2nd locking call on the already held lock deadlocks.
>>
>> Attached a backtrace with the problem and a patch/hack that "fixes" it for
>> me, but introduces a race-condition itself, so this is obviously not the
>> correct solution. The race condition would trigger if two threads would
>> simultaneously do their first call to a glX function for the same Display*
>> dpy handle, rather unlikely to happen in practice? If so, then the patch
>> might be  an acceptable fix until a better solution is found?

I changed the code to just drop the lock while we create and
initialize the glx display.  Once we're ready to add it to the list,
we take the lock again.  After making sure nobody beat us to
initializing glx on the display, we add it to the global list.  I
think that should work.

>> Other applications (glxgears, games etc.) work correctly. The difference
>> is that my toolkit calls  XInitThreads() at startup to use xlib
>> multi-threaded and afaik the locking calls only get enabled if xlib is
>> switched to thread-safe mode, otherwise they are no-ops? If i omit
>> XInitThreads() everything works again.

Yes, that makes sense, that's why I didn't see it.

thanks,
Kristian

------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to