reference counts on project NSWindows

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

reference counts on project NSWindows

Niko Matsakis
Hello,

So, I have more-or-less finished the plugin I e-mailed about earlier [1].  It inserts a WebPreview-like pane into the project window which tracks the current document.  I have one problem remaining, however, which concerns memory management.  

The plugin inserts a number of NSViews into the NSWindow.  These NSViews have an associated controller. I would like for this controller to be deallocated at the same time that the NSWindow is deallocated.  To achieve this, I am using objc_setAssociatedObject() with mode OBJC_ASSOCIATION_RETAIN to associate the object with the window; the only outstanding reference comes from this association.  When the window is released, the controller should therefore be freed.

I believe that this system works fine because I have a standalone application which also uses the same plugin code, and in that case the controller is freed once the window is freed.  Furthermore, if I observe the NSWindowWillClose notification, I see that my controller has only one outstanding reference (i.e., retainCount == 1) at the time that the window will close, and that the retain counts of the NSWindow are the same whether or not my preview code is installed into the window.

Unfortunately, when the plugin runs inside of TextMate, the controller is never freed.  I can only assume this is because the NSWindows themselves are never freed, but that seems strange.    Does anyone know a way for me to verify whether the NSWindows are being freed?  Or can anyone think of a reason that this scheme would not work in TextMate?  Or just a better scheme in general to achieve the same goal of having a controller that is freed when the window is freed?

Thanks in advance for any insight.


regards,
Niko

[1] Available from <http://github.com/nikomatsakis/SpanakopitaPlugin/> if you are curious.
_______________________________________________
textmate-plugins mailing list
[hidden email]
http://lists.macromates.com/listinfo/textmate-plugins
Reply | Threaded
Open this post in threaded view
|

Re: reference counts on project NSWindows

Niko Matsakis
While I am still curious as to what is going on here, I decided to rewrite the code to take a different approach.  Now when I see an NSWindowWillClose notification I remove my inserted views and free my own controller, which ensures that my objects are freed when the user closes the window (and, assuming I retain no references to the NSWindow, the NSWindow should be freed as well).


Niko

On Feb 6, 2010, at 10:21 AM, Niko Matsakis wrote:

> Hello,
>
> So, I have more-or-less finished the plugin I e-mailed about earlier [1].  It inserts a WebPreview-like pane into the project window which tracks the current document.  I have one problem remaining, however, which concerns memory management.  
>
> The plugin inserts a number of NSViews into the NSWindow.  These NSViews have an associated controller. I would like for this controller to be deallocated at the same time that the NSWindow is deallocated.  To achieve this, I am using objc_setAssociatedObject() with mode OBJC_ASSOCIATION_RETAIN to associate the object with the window; the only outstanding reference comes from this association.  When the window is released, the controller should therefore be freed.
>
> I believe that this system works fine because I have a standalone application which also uses the same plugin code, and in that case the controller is freed once the window is freed.  Furthermore, if I observe the NSWindowWillClose notification, I see that my controller has only one outstanding reference (i.e., retainCount == 1) at the time that the window will close, and that the retain counts of the NSWindow are the same whether or not my preview code is installed into the window.
>
> Unfortunately, when the plugin runs inside of TextMate, the controller is never freed.  I can only assume this is because the NSWindows themselves are never freed, but that seems strange.    Does anyone know a way for me to verify whether the NSWindows are being freed?  Or can anyone think of a reason that this scheme would not work in TextMate?  Or just a better scheme in general to achieve the same goal of having a controller that is freed when the window is freed?
>
> Thanks in advance for any insight.
>
>
> regards,
> Niko
>
> [1] Available from <http://github.com/nikomatsakis/SpanakopitaPlugin/> if you are curious.
> _______________________________________________
> textmate-plugins mailing list
> [hidden email]
> http://lists.macromates.com/listinfo/textmate-plugins
>

_______________________________________________
textmate-plugins mailing list
[hidden email]
http://lists.macromates.com/listinfo/textmate-plugins
Reply | Threaded
Open this post in threaded view
|

Re: reference counts on project NSWindows

Allan Odgaard-4
On 6 Feb 2010, at 11:34, Niko Matsakis wrote:

> While I am still curious as to what is going on here, I decided to  
> rewrite the code to take a different approach.  Now when I see an  
> NSWindowWillClose notification I remove my inserted views and free  
> my own controller, which ensures that my objects are freed when the  
> user closes the window (and, assuming I retain no references to the  
> NSWindow, the NSWindow should be freed as well).

I flagged your other letter to “read it in depth later” but will then  
drop that :)

It did sound like retain-cycle related. If your controller retains a  
view, that view in turn holds a pointer to its superview a.s.o. until  
it reaches the window, so indirectly your controller retains the  
window (I think, not 100% sure).


_______________________________________________
textmate-plugins mailing list
[hidden email]
http://lists.macromates.com/listinfo/textmate-plugins
Reply | Threaded
Open this post in threaded view
|

Re: reference counts on project NSWindows

Niko Matsakis
> I flagged your other letter to “read it in depth later” but will then drop that :)
>
> It did sound like retain-cycle related. If your controller retains a view, that view in turn holds a pointer to its superview a.s.o. until it reaches the window, so indirectly your controller retains the window (I think, not 100% sure).

That was my suspicion as well.  I did TRY to make sure that my controller was not retaining the window, but I may have missed something.    Anyhow, the new system seems to work well and also seems less magical, so I'm happy.


thanks,
Niko
_______________________________________________
textmate-plugins mailing list
[hidden email]
http://lists.macromates.com/listinfo/textmate-plugins