cacao objets distribués, Polling long, launchd et "Pas de réponse" dans le Moniteur d'activité

Question

Scénario:

J'ai un IPC à base Distributed objets entre une application mac et un démon launchd (écrit avec des classes Foundation). Comme j'avais déjà des problèmes concernant la messagerie asynchrone (par exemple, j'ai un registerClient: sur l'objet racine du serveur et chaque fois qu'il y a un événement notifiant l'objet racine du serveur/appelle une méthode dans l'objet proxy du client) Le client "récupère" les listes d'événements/notifications du démon. Cette "récolte" est effectuée via un appel de méthode d'objet serveur, qui renvoie ensuite une instance de NSArray. Cela fonctionne plutôt bien, jusqu'à ce que pendant quelques secondes, le processus de l'objet serveur (lancé par launchd) commence à être marqué rouge avec la balise "(Ne répond pas)" à côté (dans Activity Monitor). Comme je l'ai dit, fonctionnellement, ça marche bien, mais on veut juste se débarrasser de ce label "Ne répondant pas".

Comment puis-je empêcher cette étiquette "Ne répond pas"?

FYI, j'ai déjà fait des processus basés sur launchd auparavant et c'est la première fois que je faisais un long sondage. J'ai également essayé les connexions basées sur NSSocketPortNameServer et celles basées sur NSSocketPort. Ils n'avaient pas ce problème. Le verrouillage n'était pas aussi un problème car les verrous utilisés n'étaient que NSCondition et nous avons connecté et débogué le programme et il semble que le seul "problème" de verrouillage se trouve sur la partie récolte, qui fonctionne réellement. En outre, client-process est écrit en PyObjC pendant que le processus serveur a été écrit en utilisant ObjC.

Merci d'avance.

Answer 1

Mon problème était en fait l'appel pour obtenir le PID d'un processus en utilisant la signature FNDR ... cette partie a provoqué l'erreur "Ne répondant pas" et ce n'était jamais les verrous ou la partie à interrogation longue. Désolé pour les gars. Mais Dieu merci, j'ai déjà trouvé la réponse.

Answer 2

Sample le processus pour savoir ce qu'il fait ou attend.

Answer 3

Peter est correct dans l'approche, bien que vous puissiez être en mesure de le comprendre grâce à une simple inspection. "Ne pas répondre" signifie que vous ne traitez pas les événements de votre file d'attente d'événements pendant au moins 5 secondes (auparavant, ils étaient de 2 secondes, mais ils l'ont augmenté dans 10.4). Pour un processus d'interface utilisateur, cela crée un curseur d'attente en rotation, mais pour un processus non-interface utilisateur, vous ne voyez pas les effets aussi facilement. S'il s'agit d'un programme basé sur runloop, cela signifie que vous faites probablement quelque chose avec une opération de blocage (synchrone) qui doit être effectuée avec la boucle d'exécution et un rappel (async). Alternativement, vous avez besoin d'un deuxième thread pour traiter vos opérations de blocage afin que votre thread principal puisse continuer à répondre aux événements.