Variables partagées entre deux programmes

Bonjour,
je voulais savoir s'il y avait un moyen de partager une (ou des) variable(s) entre deux programmes, pour pouvoir influencer le fonctionnement de l'un par l'autre ?

Je pensais faire ça avec des fichiers, mais l'exécution est un peu lourde (ouverture/fermeture) et c'est surtout beaucoup moins rapide ! (C'est dans l'optique d'arrêter une boucle infinie, donc il y aurait de nombreux appel au fichier)

Si vous avez une idée, merci d'avance !

Variable d'environnement ? Pipe ? Socket (Unix ou Internet) ? IPC ?..

On peut avoir un peu plus de contexte ?

Et bien j'ai un programme que j'ai réalisé avec Qt qui communique en réseau (en TCP) avec un autre programme et reçoit des valeurs. Ces valeurs doivent servir à commander un robot programmé en ROS, or l'utilisation de ROS dans une application Qt, bien que possible, n'est pas aisée (en tout cas j'ai du mal à trouver un tuto qui marche).
En outre, la commande du robot se fait par une boucle infinie, or la valeur qui doit arrêter cette boucle est envoyée par le réseau. Ce qui fait que si j'ai les deux programmes en un (réseau et commande), le robot restera bloqué dans sa boucle (à moins de mettre la réception réseau dans la boucle, mais ça serait plus lent encore que la lecture de fichier).

C'est pour ça que j'aimerais bien utiliser une variable partagée qui stopperais la boucle du programme de commande en fonction de ce que le programme réseau a reçu.

Je sais pas si c'est suffisant.

PS : je fonctionne sous Linux.

De façon générale, la communication entre deux processus se fait par des mécanismes IPC (Interprocess communication). IL existe de nombreuses possibilités parmi lesquelles :

• Sockets TCP ou UDP/IP
• Pipes anonymes
• Pipes nommées
• Mémoire partagée
• Fichiers mappés en mémoire

Dans ton cas vu que tu communiques déjà par TCP/IP, tu as déjà le mécanisme IPC. Tu dois seulement prévoir quelque part dans ton protocole une commande qui met fin à la boucle.

Sur ton programme de commande tu dois bien pouvoir détecter que la communication réseau est coupé. En gros si ton robot ne répond plus après N essais, tu considère qu'il est coupé et tu quitte ton application.

Dans tous les cas si tes applications communiques déjà par un socket entre elle, tu n'a pas de raisons d'introduire un deuxième canal entre les deux.

Mon programme de commande n'a aucune interface réseau, tout se passe dans le programme Qt. Pour résumer, voici un schéma :

Ce que je cherche c'est le lien ?. Je vais déjà regardé du côté de ce que m'a dit QuentinC

Alors, après renseignement, je dirais que les tubes nommés et les mémoires partagées correspondent à ceux que je veux faire. J'ai trouvé deux tutos là-dessus qui m'ont assez bien expliqué le fonctionnement (surtout le tut du sdz), voir les liens.

Je n'ai pas encore testé les deux méthodes de moi-même, je le ferais demain. Mais dans le cas où celles-ci ce révèlent identiques dans leur fonctionnement, y a-t-il une raison particulière qui pourrais me faire préférer une solution plutôt qu'une autre ?

Merci encore !

JE pense que ça serait quand même dommage de multiplier les tuyaux de communication. Parce que là, ça ressemble un peu à on parle au téléphone, et tu m'envoies un SMS pour me dire que tu vas couper; ça serait plus logique de me dire au-revoir directement non ?

En plus avec plusieurs canaux ouverts simultanément, tu vas probablement te frotter aux problèmes de synchronisation; c'est souvent chiant et compliqué à débugger.

Oui, je suis d'accord qu'il serait plus logique de commander directement le robot avec mon application Qt, sachant qu'il y a un nœud que je n'ai pas représenté (il y a un programme qui envoie les données à l'applications Qt cliente).
Cependant, j'ai du mal à utiliser ROS avec mon applications Qt, les docs que je trouve ne sont pas super bien expliquée, tout ce que j'ai tenté a échoué. De plus, la commande du robot se fait dans une boucle qui doit être arrêtée par une commande reçue en TCP. Et je ne sais pas si une boucle est bloquante pour le système de signaux et de slots de Qt.