Re: DO and "leaked" connection object

[Chan Maxthon]

Really, you should make that connection an instance variable or private 
property, and then ARC it.

发自我的 iPhone

在 2013-2-5，18:06，Richard Frith-Macdonald <address@hidden> 写道：

> 
> On 5 Feb 2013, at 09:42, Riccardo Mottola wrote:
> 
>> Maxthon Chan wrote:
>>> Just an idea, will ARC work?
>> I don't know what it ARC would do in this situation, perhaps knowing
>> that can help me putting the rlease in the correct place. I don't
>> like/use it. In any case I want to understand what should be done with
>> the connection.
>> I don't hitnk this is a seirous error, but I want to understand.
> 
> I expect if you used ARC, your program would fail rather than leaking.
> The reason is, the compiler would see the instance variable go out of scope, 
> and release the NSConnection object ... so your code would be unabel to 
> accept incoming messages.
> 
> The rules here are nothing special ... you need to retain an object until you 
> no longer want to use it.
> In this case you say you want to keep the connection until the program ends 
> (so you can get messages from other apps), so the correct behavior is to keep 
> the object retained until the program ends ... which is what your code does.
> The compiler is warning you because it sees the variable go out of scope (at 
> which point it becomes impossible for you to release it), but that's harmless 
> because you never want to release it.
> 
> That being said, the compiler is warning you about a bad practice ... you 
> really should use a global variable or instance variable.
> Not only will doing that avoid the compiler warning, it will also allow you 
> to release the connection explicitly on or before program termination.
> 
> I like to invalidate and release connections immediately before shutdown, in 
> order to ensure that messages from other apps don't arrive while in the 
> process of shutting down.  If your app has a complicated clean-up process 
> when it shuts down, an incoming message at that point could mess things up, 
> so it's simpler to stop accepting messages and then do other cleanup.