On Jul 7, 2014, at 22:10, Gerriet M. Denkmann < email@hidden> wrote:
On 8 Jul 2014, at 10:57, Clark S. Cox III <email@hidden> wrote:
On Jul 7, 2014, at 20:36, Gerriet M. Denkmann <email@hidden> wrote:
On 8 Jul 2014, at 10:03, Roland King <email@hidden> wrote:
Why are you making self unowned?
I have no idea.
The Swift book (in the chapter "“Resolving Strong Reference Cycles for Closures”) seems to say that this is the correct way to "resolve a strong reference cycle between a closure and a class instance”.
Not quite - it says unowned if the block and self have the same lifetime, else weak.
The book says: “If the captured reference will never become nil, it should always be captured as an unowned reference, rather than a weak reference.”
And I can think of no way how "self" = instance of my Crash class could ever become nil while its function makeCrash is running.
Believe me, it can. Nothing after that point has a strong reference to self (because the only remaining reference to self is inside of the closure, but you made that particular reference “unowned”), the compiler is free to release it after the closure is created, but before dispatch_apply is called.
But the caller of makeCrash has a strong reference to self via let dummy = Crash()does this not keep the instance of Crash alive?
No, because the compiler can see that dummy is never used again after the call to makeCrash.
Anyway: even without "[unowned self]" I always see a println() inside of deinit{} (if it is not crashing before).
Which might indicate that there are no evil retain-cycles taking place.
There are indeed no retain cycles.
The only thing referencing self is the closure
The only thing referencing the closure is the code inside of dispatch_apply
Once dispatch_apply is done, the closure is released and deallocated
Once the closure is deallocated, the reference it holds on self is released
Could anybody show me some example which really needs [unowned self] or [weak self] to break a retain-cycle?
If, for instance, you stored the closure in a property on self, that would create a retain cycle that would need breaking.
To sum up:There are no retain cycles in my example, so one does NOT need [unowned self].And using [unowned self] is dangerous, because "self" might go away while dispatch_apply is still running.Correct?
Correct. “unowned” is essentially telling the compiler “don’t count this reference, assume that I know what I’m doing and I have something else that will keep the referenced object alive”. However, in this case, nothing else is keeping the object alive, and the compiler trustingly attempts to access the now destroyed object and that leads to the crash. What I not understand: dispatch_apply() returns after all threads have finished (Correct?).
Correct. To execute code after dispatch_apply() has finished, self must still exist.
If, in makeCrash, you used self after the dispatch_apply, then the compiler would see that it still has a reference and self would still exist. What about:
if something
{
let myClosure = ... // closure NOT using [unowned self] but referencing "self"
dispatch_apply( nbr, queue, myClosure)
somethingElse( myClosure )
// now myClosure gets out of scope and hopefully disappears, removing its reference to self
}
would this be safe, i.e. have no retain-cycles?
Yes, assuming that somethingElse doesn’t end up doing something to cause a cycle (e.g. storing the closure in one of self’s properties)
|