Re: NSWindowController, bindings and Garbage Collection
Re: NSWindowController, bindings and Garbage Collection
- Subject: Re: NSWindowController, bindings and Garbage Collection
- From: Nikita Zhuk <email@hidden>
- Date: Wed, 25 Feb 2009 09:44:15 +0200
I think I've found a workaround for this problem.
It seems that the model object is accessed from the GC thread's
finalize only when the keyPath to which a value is bound contains at
least three components. For example, if a value in the window is bound
to "model.name" property, my model isn't touched from GC thread's
finalize. If keypath is "model.subModel.name", methods of my model are
called from GC thread's finalize.
So the workaround seems to be to use keypaths with only two components.
On 24.2.2009, at 22.22, Nikita Zhuk wrote:
I'm running a Cocoa application with Garbage Collection enabled,
linking against 10.5 SDK. My application has a NSWindowController
subclass which instantiates a window from a nib file (-
[NSWindowController initWithWindowNibName:]) and acts as the File's
owner of that nib. The window in the nib has several controls with
values bound to properties of a model object, which is accessible
through the File's owner. The model object assumes that all method
calls made to retrieve its values are made in the main thread - it
has assertions which verify that this is the case.
Under manually managed memory this works as expected - all bound
values are fetched from the model object on the main thread and
file's owner is deallocated after the window is closed. When the
application is compiled and run with GC, file's owner is collected
(finalize is run), but after a while NSBinder instance accesses my
model class from a subthread, causing the "main thread only"
assertion of my model class to fail with the following stack trace:
#2 0x0000a3aa in -[MyModelObject mainThreadOnlyMethod:] at
MyModelObject.m:123
#3 0x936ebf6b in _NSGetUsingKeyValueGetter
#4 0x936eba07 in -[NSObject(NSKeyValueCoding) valueForKey:]
#5 0x9376aa01 in -[NSKeyValueNestedProperty
object:didRemoveObservance:]
#6 0x93749c43 in -[NSObject(NSKeyValueObserverRegistration)
_removeObserver:forProperty:]
#7 0x937499e4 in -[NSObject(NSKeyValueObserverRegistration)
removeObserver:forKeyPath:]
#8 0x9376aa21 in -[NSKeyValueNestedProperty
object:didRemoveObservance:]
#9 0x93749c43 in -[NSObject(NSKeyValueObserverRegistration)
_removeObserver:forProperty:]
#10 0x937499e4 in -[NSObject(NSKeyValueObserverRegistration)
removeObserver:forKeyPath:]
#11 0x93b3f690 in -[NSBinder _updateObservingRegistration:]
#12 0x93b85d0f in -[NSBinder
releaseConnectionWithSynchronizePeerBinders:]
#13 0x93d288c8 in -[NSBinder finalize]
#14 0x933546b6 in finalizeOneObject
#15 0x91488dab in foreach_block_do
#16 0x9335487b in batchFinalize
#17 0x93354b42 in batchFinalizeOnTwoThreads
#18 0x91489f0e in auto_collect_internal
#19 0x9148ab8f in auto_collection_thread
#20 0x9559a095 in _pthread_start
#21 0x95599f52 in thread_start
There have been a similar problem reported earlier when using Core
Data, bindings and GC [1]. The problem seem to be the same. How this
could be prevented or worked around? My model objects must remain
main-thread-only. Would the "NSObjectController as a file file's
owner" pattern [2] help here?
[1] http://www.mail-archive.com/email@hidden/
msg17346.html
[2] http://www.borkware.com/quickies/do-search?search=nsobjectcontroller
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden