Распределенные объекты какао, длительный опрос, запуск и «не отвечает» в мониторе активности

Question

Сценарий:

У меня есть IPC на основе распределенных объектов между приложением Mac и демоном launchd (написанным с помощью классов Foundation). Поскольку раньше у меня были проблемы с асинхронным обменом сообщениями (например, у меня есть registerClient: на корневом объекте сервера и всякий раз, когда происходит событие, корневой объект сервера уведомляет / вызывает метод в прокси-объекте клиента), я выполнил длинный опрос, который означал, что клиент "собирает" списки событий / уведомлений от демона. Этот "сбор" выполняется с помощью вызова метода объекта сервера, который затем возвращает экземпляр NSArray.

Это работает довольно хорошо, пока в течение нескольких секунд процесс объекта сервера (запущенный через launchd) не будет помечен красным с тегом "(Не отвечает)" рядом с ним (внутри Activity Monitor). Как я уже сказал, функционально это работает хорошо, но мы просто хотим избавиться от этого ярлыка «Не отвечает».

Как я могу предотвратить этот тег "Не отвечает"?

К вашему сведению, я уже делал процессы, основанные на запуске, и это первый раз, когда я проводил длинный опрос. Кроме того, я попробовал соединения на основе NSSocketPortNameServer, а также соединения на основе NSSocketPort. У них не было этой проблемы. Блокировка не была также проблемой, потому что используемые блокировки были только NSCondition, и мы зарегистрировали и отладили программу, и кажется, что единственная проблема блокировки связана с частью сбора, которая фактически работает функционально. Кроме того, клиентский процесс написан на PyObjC, а серверный процесс написан на ObjC.

Заранее спасибо.

Answer 1

Питер прав в подходе, хотя вы можете выяснить это с помощью простого осмотра. «Не отвечает» означает, что вы не обрабатываете события в своей очереди событий в течение как минимум 5 секунд (раньше было 2 секунды, но они повысили его за 10,4). Для процесса пользовательского интерфейса это создаст вращающийся курсор ожидания, но для процесса, не относящегося к пользовательскому интерфейсу, вы не так легко видите эффекты.

Если это программа на основе runloop, это означает, что вы, вероятно, делаете что-то с блокирующей (синхронной) операцией, которая должна выполняться с циклом выполнения и обратным вызовом (асинхронным). Кроме того, вам нужен второй поток для обработки операций блокировки, чтобы ваша основная тема могла продолжать отвечать на события.

Answer 2

На самом деле моей проблемой был вызов для получения PID процесса с использованием подписи FNDR ... эта часть вызвала ошибку «Не отвечает», и это никогда не было блокировками или частью длинного опроса. Извините за это, ребята. Но, слава Богу, я уже нашел ответ.

Answer 3

Пример процесс, чтобы узнать, что он делает или ждет.