Re: [gtk-osx-users] Lion, NSUserDefaults, Threading, Python and Deadlock?

[John Ralls <jralls ceridwen us>]

On Dec 8, 2011, at 4:53 PM, Richard Procter wrote:

> Hi Everyone, 
> 
> My application has been freezing on Lion (call trace below). This is a tentative heads-up for anyone using pygtk and the NSUserDefaults system on Lion. 
> 
> It appears that Lion has new asynchronous NSUserDefaults code(*) handled by the 'wqthread'. This looks to synchronise preferences in the background. However it tries to acquire the python GIL lock at some point, which I am assuming is in order to notify the module-global AppKit.NSUserDefaults.standardUserDefaults() object in my python code.
> 
> I suppose this is leading to deadlock as follows: 
> 
> 
>  pygtk thread 
>     - ACQUIRES GIL lock 
>  [...]
>  wqthread wakes up to synchronize preferences, 
>     - ACQUIRES some NSUserDefaults lock
>     - WAITS on GIL lock held by pygtk thread, I am assuming in order to notify my NSDefaults python object
>  [..] 
>  pygtk thread tries to do something with preferences 
>     - WAITS on the same NSUserDefaults lock held by wqthread  
> 
> 
> In this case gtk is reading the NSUserDefaults for the doubleClickThreshold in quartz/gdkevents-quartz.c (**) but I presume the same scenario could occur from my python level use, too.   
> 
> So, assuming this is right, what to do? 
> 
>  a) Break the GIL depedency: 
>        - AppKit to relenquish GIL lock when accessing NSUserDefaults (via some specialcase workaround module?) 
>        - asynchronous defaults update code to refrain from triggering a call into python
>  b) Break the NSUserDefaults lock dependency: 
>        - no go, as we need to serialise Preferences access at some level. 
>  c) Limit the lifetime of my python NSUserDefaults object 
>        - minimises but does not eliminate the problem as the same scenario can still occur. 
>  d) Don't use NSUserDefaults in python or gtk 
> 
> 

The GIL is a python thing, AFAIK, so neither gdk-quartz nor AppKit know anything about it, and neither calls into Python. Notifications are to the NSApplicationDelegate, not to an NSUserDefaults object, so that's not likely to be the problem either. CFPreferences has always handled its own access serialization, that release note only says that they've made it better.

Regards,
John Ralls