Re: Swift crash in dispatch_apply
Re: Swift crash in dispatch_apply
- Subject: Re: Swift crash in dispatch_apply
- From: "Clark S. Cox III" <email@hidden>
- Date: Mon, 07 Jul 2014 20:57:29 -0700
> 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.
> 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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden