CODEWITHSUNDEEP
iosswiftautomatic-ref-counting
Andre Liberty
Andre Liberty

Reputation: 757

Can an object be deallocated during method execution?

Let's assume that we create an instance of class var foo: Foo? = Foo() on the main thread and we call some time consuming instance method bar of Foo on another thread, after a short time we set foo to nil on main thread. What happens with the execution of bar, in my understanding bar should still continue its execution since invoking instance method implicitly passes self as the first argument, so even those the last explicit ref to foo was broken we still have a ref inside of a method and it should be good. But then I found this stackoverflow post which completely breaks my understanding. So, can somebody confirm/deny the fact that object cannot be deallocated during its method execution

Upvotes: 0

Views: 542

Answers (1)

Rob Napier
Rob Napier

Reputation: 299305

Short answer is that your belief is correct, and you're looking at a question that's not relevant to Swift.

Your link is to non-ARC Objective-C. Swift always uses ARC, and ARC is very conservative about retains. Consider the following Objective-C call:

[target runMethod: parameter];

Under ARC, this is (conceptually) transformed into:

[target retain];
[parameter retain];
[target runMethod: parameter];
[parameter release];
[target release];

retain and release are atomic, thread-safe calls.

A similar behavior exists in Swift. Because of this, as a general rule (in the absence of Unsafe), a variable cannot "disappear" while you'll holding onto it.

This is the implementation detail. The better way to think about it is that by default variables and parameters are strong, and an object cannot be destroyed while there is a strong reference. This matches your understanding.

Prior to ARC, though, you needed to insert extra retains and releases yourself to protect against this kind of situation, and it was very common not to. (Prior to 10.6, most ObjC was single-threaded.)

Even without threads, there are ways this can go astray without ARC. Since callers often didn't immediately retain returned values if they only needed them temporarily, it was possible to get dangling pointers even without multiple threads. For example, with a trivial accessor with no memory management, this can crash:

NSString *name = [person name];
[person release];
[self doSomethingWithName: name];

This is why you often see old ObjC getters written in the form:

- (NSString*) title {
    return [[title retain] autorelease];
}

This made sure that the returned value would survive until the end of the event loop even if self released it or self was deallocated.

Swift does similar things via ARC, but as the name suggests, it's all automatic.

Upvotes: 3

Related Questions