Cacau Objetos Distribuídos, Longo Polling, launchd e “não responde” no Activity Monitor

Question

Cenário:

Eu tenho um IPC-based-objetos distribuídos entre um aplicativo mac e um daemon launchd (escrito com Foundation Classes). Desde que eu tive problemas antes sobre mensagens assíncronas (por exemplo, eu tenho um registerClient: no objeto raiz do servidor e sempre que há um evento notifica objeto raiz do servidor / chama um método no objeto de proxy do cliente), eu fiz a longo polling que significava que o cliente "colhe" listas de eventos / notificações do daemon. Este "colheita" é feito através de uma chamada de método do objeto servidor, que, em seguida, retorna uma instância NSArray.

Ele funciona muito bem, até que por alguns segundos, o processo do objeto de servidor (lançado através launchd) começa a ser rotulado vermelho com o "(não responder)" tag ao seu lado (dentro Activity Monitor). Como eu disse, funcionalmente, ele funciona bem, mas nós simplesmente querem se livrar deste rótulo "não responde".

Como posso evitar que isso tag "não responde"?

FYI, eu já fiz processos baseados em launchd antes e esta é a primeira vez que fiz a longo polling. Além disso, eu tentei conexões baseadas em NSSocketPortNameServer e queridos também baseados em NSSocketPort. Eles não têm esse problema. Bloqueio não era também uma questão 'coz as fechaduras utilizadas foram apenas NSCondition e nós registrados e depurado o programa e parece que a única bloqueio 'questão' é na parte da colheita, que na verdade, funcionalmente funciona. Além disso, o cliente-processo é escrito em PyObjC enquanto processo do servidor foi escrito usando ObjC.

Agradecemos antecipadamente.

Answer 1

O meu problema era realmente a chamada para obter PID de um processo usando a FNDR assinatura ... que parte fez com que o "não está respondendo" erro e nunca foi as fechaduras ou a parte longa-polling. Desculpe por isso caras. Mas graças a Deus eu já encontrei a resposta.

Answer 2

Amostra o processo de encontrar o que ele está fazendo ou esperando.

Answer 3

Pedro correta na abordagem, mas você pode ser capaz de descobrir isso através de inspeção simples. "Não está respondendo" significa que você não está processando eventos em sua fila de eventos por pelo menos 5 segundos (costumava ser 2 segundos, mas elevou-o em 10,4). Para um processo de interface do usuário, isso iria criar um cursor de espera fiação, mas por um processo não-UI, você não está vendo os efeitos tão facilmente.

Se este é um programa baseado em RunLoop, isso significa que você provavelmente está fazendo algo com uma operação de bloqueio (síncrono) que deve ser feito com o loop de execução e uma chamada de retorno (assíncrona). Como alternativa, você precisa de um segundo segmento para processar suas operações de bloqueio para que o seu mainthread pode continuar a responder a eventos.