Objets distribués Cocoa, interrogation longue, launchd et "pas de réponse" & # 8221; dans le moniteur d'activité

Question

Scénario:

J'ai un IPC basé sur des objets distribués entre une application Mac et un démon launchd (écrit avec les classes Foundation). Comme j'avais auparavant 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, l'objet racine du serveur notifie / appelle une méthode dans l'objet proxy du client), j'ai effectué une longue interrogation, ce qui signifiait que client " récoltes " listes d'événements / notifications du démon. Cette " récolte " se fait via un appel de méthode objet serveur, qui renvoie ensuite une instance de NSArray.

Cela fonctionne plutôt bien, jusqu'à ce que le processus de l'objet serveur (lancé via launchd) commence à être étiqueté en rouge avec le signe "(ne répond pas)". balise à côté (dans Activity Monitor). Comme je l’ai dit, cela fonctionne bien sur le plan fonctionnel, mais nous voulons simplement nous débarrasser de ce message "Ne répond pas". étiquette.

Comment puis-je éviter ce problème? "Ne répond pas". tag?

Pour info, j’avais déjà déjà utilisé des processus launchd et c’est la première fois que je fais des sondages longs. De plus, j'ai 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 également un problème car les verrous utilisés n’étaient que du code NSCondition et nous avons consigné et débogué le programme et il semble que ce soit le seul "problème" de verrouillage. est sur la partie de la récolte, qui fonctionne réellement, fonctionnellement. De plus, client-processus est écrit en PyObjC alors que le processus du serveur a été écrit avec ObjC.

Merci d'avance.

Answer 1

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

Answer 2

Échantillon du processus à suivre ce qu’il fait ou attend.

Answer 3

Peter a raison dans son approche, mais vous pourrez peut-être le découvrir grâce à une simple inspection. " ne répond pas " signifie que vous ne traitez pas les événements de votre file d'attente pendant au moins 5 secondes (auparavant, c'était 2 secondes, mais ils l'ont augmenté en 10.4). Pour un processus d'interface utilisateur, cela créerait un curseur d'attente en rotation, mais pour un processus sans interface utilisateur, vous ne verrez pas les effets aussi facilement.

S'il s'agit d'un programme basé sur runloop, cela signifie que vous effectuez probablement quelque chose avec une opération de blocage (synchrone) qui devrait être effectuée avec la boucle d'exécution et un rappel (asynchrone). Sinon, 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.