Skip to content

FIX: GilSafeSingleLock is causing UI freeze when it cannot get the GIL back... #1204

Closed
wants to merge 1 commit into from

4 participants

@koying
Team Kodi member
koying commented Jul 22, 2012

... 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

@koying koying FIX: GilSafeSingleLock is causing UI freeze when it cannot get the GI…
…L back while having already locked the graphic context. Removing it.
1ad325a
@garbear

cosmetic (two little spaces thought they could come along for the ride :))

@jmarshallnz

Above this you call PyThreadState_Get() when setting the callback. What implications (if any) does this have while you're not holding the GIL?

Team Kodi member

ACK, You need the GIL for PyThreadState_Get.

@jmarshallnz

above this you're accessing python functions without the GIL?

Team Kodi member

ACK

@jmarshallnz
Team Kodi member

@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.

@koying
Team Kodi member
koying commented Jul 23, 2012

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...

@jimfcarroll
Team Kodi member

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).

@koying
Team Kodi member
koying commented Jul 23, 2012

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.

@koying koying closed this Oct 11, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.