Цель-C: избежать ИСКЛЮЧЕНИЙ, когда сбой NSConnection к распределенным объектам

Question

Я использую Objective-C Distributed Objects (DO) для обмена данными из одного приложения (которое собирает данные из сети) в другое (патч внутри Quartz Composer). Когда не удается подключиться к удаленному объекту (когда я закрываю первое приложение), я получаю:

5/16/12 8:17:06.373 PM Quartz Composer: *** EXCEPTION IGNORED: connection went invalid while waiting for a reply because a mach port died

После этого кварцевая композиция подвешена. Даже после того, как я восстановил первое приложение, оно все еще зависло. Я хочу, чтобы Кварцевый патч восстановил соединение.

Я использую Центр уведомлений, чтобы закрыть старые объекты, например так:

[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(connectionDidDie)
                                             name:NSConnectionDidDieNotification
                                           object:theConnection];

Прямо сейчас мой counnectionDidDie выглядит так:

- (void) connectionDidDie
{
    NSLog(@"Connection died and we detected it");
    [[self proxyObject] release];
    [self setProxyObject:nil];
    theConnection = nil;
}

Я также проверяю, чтобы убедиться, что соединение все еще живо, непосредственно перед доступом к любой части proxyObject, например:

if ([NSConnection defaultConnection]) { // this line triggers the exception
    // access proxyObject
}

Я также пытался

if ([theConnection isValid]) { // this line triggers the exception
    // access proxyObject
}

В обоих случаях именно этот тест вызывает это ИСКЛЮЧЕНИЕ.

Что я могу сделать, чтобы предотвратить зависание Quartz при завершении работы первого приложения, у которого есть объект, который был продан?

Answer 1

Мне никогда не удавалось найти способ достаточно быстро отключить соединение DO, чтобы предотвратить QC, который рисует со скоростью 30-60 кадров в секунду, тестирует фронтальное соединение (и падает) перед вызовом connectionDidDie:. В конечном счете, я решил использовать DO, только чтобы получить начальную копию объекта, которая затем делает глубокую копию, а затем уничтожает соединение DO, пока ничто не пытается получить к нему доступ. DO просто не кажется таким уж хорошим решением, после того, как вы окунетесь в него.:(