Re: [gtk-osx-users] Lion, NSUserDefaults, Threading, Python and Deadlock?
- From: Richard Procter <richard n procter gmail com>
- To: gtk-osx-users-list gnome org
- Subject: Re: [gtk-osx-users] Lion, NSUserDefaults, Threading, Python and Deadlock?
- Date: Wed, 14 Dec 2011 12:45:37 +1300
On 9/12/2011, at 1: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.
I've fixed this now. Here's what I think was happening:
I was wrong to believe (and after looking carefully at the pygobject and python code!) that pygtk was releasing the GIL lock upon entry to gtk.main(). Apparently an explicit call to gobject.init_threads() is required to enable pygtk release of the GIL, without which the deadlock I outlined is almost guaranteed.
The problem appeared with Lion and I believe this is because Apple have added a new pthread work queue to handle NSUserDefaults synchronisation, which is consistent with their release notes. That thread called into python as a side-effect of releasing an object I had presumably passed through from python (via the PyObjC bridge) at some point, probably a python string literal.
The lesson is: Lion implicitly forces multithreading on an ostensibly single-threaded pygtk application if you pass python parameters to AppKit.NSUserDefaults (provided by the PyObjC bridge to AppKit).
And I wonder if Apple's seemingly benign and useful --- but complicating --- improvement has created a new class of potential problems for other software more generally?
best,
Richard.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]