... while having already locked the graphic context.
This happens (for me), for instance, during lengthy mysql operations in python while another script tries a simple "window.setProperty".
Removing it and using the separate ad-hoc locking mechanisms. Reference: Pull Request #797
FIX: GilSafeSingleLock is causing UI freeze when it cannot get the GI…
…L back while having already locked the graphic context. Removing it.
cosmetic (two little spaces thought they could come along for the ride :))
Above this you call PyThreadState_Get() when setting the callback. What implications (if any) does this have while you're not holding the GIL?
ACK, You need the GIL for PyThreadState_Get.
above this you're accessing python functions without the GIL?
@jimfcarroll a review would be good - a few places we're calling python routines while in the scope of CPyThreadState that I'm not sure about.
Actually, looks like all CGUIWindowManager functions are already locking the graphic context, so I wonder if it is even necessary to recurse lock it in the windows.cpp functions... Will test...
My concern here is whether or not you considered that calls made from these methods assume the GIL is held and not just what's visible here. For example, you are now calling "new CGUIPythonWindowXMLDialog" without holding the GIL. Did you check that all possible call stacks resulting from all calls where you no longer are holding the GIL nowhere assume you were holding the GIL?
This is why I did it the way I did in the first place. Not that I think it was the right answer (The right answer is in my PR).
I checked as far as possible that called functions were not calling python.
But my problem is actually related to the graphic context lock, not the GIL. As far as my problem is concerned, the functions can have the GIL as long as the UI is not locked while we are waiting to obtain it, as was done with GilSafeSingleLock.
So, if someone could confirm the "CSingleLock lock(g_graphicsContext);"'s are not needed because the locking is properly done in the xbmc window functions, that would solve the original problem, the windows.cpp could keep the GIL and no "CPyThreadState" would even be necessary.