MCSession takes a long time to dealloc

Question

I'm using Multipeer-Connectivity.

When the session ends, the app comes to the main menu and all network stuff is released then deallocated.

But my dealloc method is called in main thread and the MCSession object takes a very long time to release itself, I don't know why, and consequently the main menu screen freezes.

If somebody know why MCSession could be so long, I'm interested. But if it comes from the MCSession itself, is it a good solution to do this?

-(void) dealloc
{
    //... other release

    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        [_session release];
        _session = nil;
    });

    [super dealloc];
}

EDIT: nope, it's definitely not a good solution, because it makes my app crashing. Anyway, other ideas?

bsarr007 · Accepted Answer · 2014-02-04T19:54:57.097

2

When you call [_session release] since _session is an Ivar, the compiler will replace this line by [self->_session release] and the block will retain self instead of the iVar _session. Here you have 2 problems:

Trying to retain an object(self) which are deallocating.
When the queue will be executed, it'll call self which is already deallocated.

The following solution create a local variable which point to the same address as the iVar and release it inside the block, the block will not capture self.

-(void) dealloc
{
    //... other release
    MCSession* localSession = _session;
    dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
        [localSession release];
    });

    [super dealloc];
}

edited Feb 04 '14 at 19:54

answered Feb 03 '14 at 18:31

bsarr007

1,914
14
14

"can you explain why does this work?" - MCSession normally operates on the main thread. It takes a long time to disconnect and that is what it does before it releases. During that long time the main thread is blocked. By placing this task on a separate thread the main thread is not blocked and your app continues while MCSession blocks its new thread. Alternatively you could put your next task on a new thread. Blocking a thread does not prevent the next lines of code from executing - but there will be no animations like UIAlerts or presentViewController – Peter B. Kramer Apr 08 '14 at 19:25
As you can see, the solution i proposed is just to avoid to try to retain self (using the iVar) inside the dealloc which is a mistake. – bsarr007 Apr 09 '14 at 07:47

score 2 · Answer 2 · answered Mar 20 '14 at 15:52

bsarr007's solution will work for non-ARC projects. If you are using ARC, you can try this:

__block MCSession *localSession = _session;
_session = nil;
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0), ^{
    oldSession = nil;
});

It works for me. What I am doing here is increasing reference count of MCSession object by creating new local variable that points to that object, so it won't be deallocated immediately when setting _session = nil. After that I am running asynchronously the code that decreasing reference counter of my MCSession object using background queue.

Yes, my solution like the question is for non ARC project. – bsarr007 Apr 09 '14 at 07:45 — bsarr007, Apr 09 '14 at 07:45

MCSession takes a long time to dealloc

2 Answers2