Communication entre deux applications

02:37 modifié dans API AppKit #1
Bonjour,

Je vous expose un problème relatif au projet XDev. Il concerne la communication entre les deux applications (le débogueur (XDDebugger) et l'application maà®tre (XDev)). XDDebugger exécute l'application construite tandis que XDev affiche l'éditeur de débogage (piles des appels, variables ainsi que le code où à  lieu l'arrêt). J'ai utilisé les DO pour la communication entre XDDebugger et XDev car je doit récupérer l'ensemble du contexte du runtime. Dans ce cas, je n'ai pas le choix et celà  fonctionne bien.
Mon interrogation concerne la liaison inverse. J'ai d'abord utiliser un thread pour scruter l'état de XDDebugger au niveau de XDev. Je sais que cette approche est l'une des plus mauvaises. Il s'agit d'attente active. Au lieu d'employer les DOs que me proposez-vous comme solution alternative ?

Merci de votre aide.

Réponses

  • NoNo Membre
    02:37 modifié #2
    2 réponses me viennent à  l'esprit (mais il en existe d'autres) :
    - les signaux,
    - les apple events.

    Tous 2 nécessitent l'installation d'un handler dans l'application qui va recevoir. Il n'y a donc pas de polling (ce que tu nommes attente active), puisque la fonction enregistrée auprès du handler ne sera exécuté que sur réception du signal ou de l'AE.
  • schlumschlum Membre
    02:37 modifié #3
    L'attente est forcément active quelque part... Que ça soit dans un thread ou au passage dans une runloop.

    Sinon, d'autres moyens de communication inter-process :
    - La mémoire partagée
    - Un fichier mappé (la solution la plus intéressante car permet de conserver l'état pour comprendre des choses en cas de crash)
    - Un pipe nommé
  • 02:37 modifié #4
    Merci pour ces suggestions. Je vais cogiter  .
  • tabliertablier Membre
    mai 2009 modifié #5
    Je suis en train d'écrire un tutoriel sur les Apple Events. La section 2 du chapitre 1 est un résumé d'un texte de Apple sur les "Interprocess communications" qui existe dans la doc de Xcode 2.5.
      :P Je pense que ça peut t'interresser, même si ça ne te donne pas directement la solution.
  • 02:37 modifié #6
    @Tablier
    Très bien. Les Apple Events ont toujours été pour moi obscurs. C'est toujours très utile de disposer de plusieurs solutions car celà  permet de choisir celle la plus appropriée.

    Par ailleurs, j'ai trouvé deux applis "PictureSharing" et "PictureSharingBrowser" qui exploitent les classes NSNetService, NSFileHandle ainsi que sockets BSD, pour ne citer que celles-là .
    Je vais les étudier car je pense qu'elles réalisent la fonctionalité que je recherche.

  • AliGatorAliGator Membre, Modérateur
    02:37 modifié #7
    Pour l'avoir déjà  testé et avoir travaillé avec Bonjour (et encore maintenant), cet exemple est bien... mais très orienté Bonjour plus que sur l'échange en soi. De plus et surtout l'échange dans ces exemples est basé sur les sockets BSD, qui en soi ne sont pas si compliqués que ça si on a déjà  bossé avec, mais bon ne sont pas les premiers trucs que je conseillerai d'utiliser pour se lancer là  dedans. En plus l'utilisation des sockets a beaucoup plus d'intérêt pour la communication réseau pour lesquels ils sont utilisés massivement (même si je sais que c'est possible, genre via des interfaces loopback, je crois n'avoir jamais vu l'utilisation des sockets pour de la communication interprocess sur un même host)

    La communication entre applications se fait plutôt soit par les signaux ou les pipes, ou les AppleEvents, ou les NSDistributedNotificationCenters... ce genre de truc.
  • zoczoc Membre
    02:37 modifié #8
    dans 1242307824:

    - La mémoire partagée
    - Un fichier mappé (la solution la plus intéressante car permet de conserver l'état pour comprendre des choses en cas de crash)
    - Un pipe nommé


    Ou encore Cocoa Distributed Objects
  • 02:37 modifié #9
    J'ai essayé NSDistributedNotificationObject et celà  répond parfaitement à  mes attentes. C'est très simple à  utiliser.

    Merci Ali.


Connectez-vous ou Inscrivez-vous pour répondre.