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

[John Ralls <jralls ceridwen us>]

On Dec 11, 2011, at 2:30 PM, Richard Procter wrote:

> Hi John, 
> 
> Thanks for the info. As this doesn't look to be a specifically pygtk or gtk-osx related issue I won't clog up the list further until I resolve it one way or the other. 
> 
> In the meantime I'll respond to your points below for anyone following this.  
> 
> On 10/12/2011, at 9:42 AM, John Ralls wrote:
>> 
>> The GIL is a python thing, AFAIK, so neither gdk-quartz nor AppKit know anything about it, and neither calls into Python.
> 
> That was my understanding, too, but note the stack traces below. Although it's an unthreaded pygtk application, in the 'wqthread' (i.e. non Py_Main()) thread we see a call into PyEval_RestoreThread() during an invocation of [CFXPreferencesPropertyListSource synchronizeInBackgroundWithCompletionBlock:], which, if I am reading it right, is blocking trying to acquire the GIL. 
> 
> The trace suggests to me that the preference system is keeping some object alive until the next synchronisation (in a helper thread), whereupon its PyObjC destructor calls into python and blocks on the GIL. 
> 
> That said, I would expect the _wrap_gtk_main() call to have released the GIL (via its call to pyg_begin_allow_threads, which releases the GIL via PyEval_SaveThread()), which should be sufficient to prevent the deadlock scenario I outlined. 

So perhaps PyObjc has registered a callback or overridden a method to maintain control of the threading... in which case its threading and PyGtk's would be fighting.

Maybe you should write your NSUserPrefs accessor in Objective-C, put it in a little library, and wrap it for Python.

Regards,
John Ralls