Bonjour,
je suis en train de codé un ensemble de programme déstiné à être intégré dans un robot ( PC Embarqué sous Linux ) et j'ai préféré séparé la fonction global en plusieurs sous systèmes pour une plus grande facilité de débuggage et je l'espère une plus grande stabilité de l'ensemble ( je compte réaliser un petit prog qui surveille l'execution et relance le prog en cas de plantage )
Seulement voila, il est venu le temps de faire 'communiquer' les programmes entre eux, il y a une sorte d'architecture client/serveur avec 2 programmes qui jouent le rôle de serveur, et 1 prog qui récupère tous ca.
J'ai déja lu quelques trucs sur les IPC & co mais ils s'agient le plus souvent de communication entre thread, avec des processus parents & fils. Mais dans mon cas ils s'agient de processus au lancement completement séparé, mais qui doivent se synchroniser.
Donc pour cela j'avais pensser faire comme cela, dites moi ce que vous en penssez
Le serveur ouvre un 'partage' IPC au démarrage et met la clef dans un fichier au nom constant.
Le client ouvre le fichier, recupère le clef, et ouvre le partage avec cette clef, ensuite il lui suffit d'utiliser les données quand il en a besoin.
Les problèmes qui pourrait survenir sont tout d'abord des problèmes d'accès, je ne sais pas ce qu'il adviendrait si cela arrivé ( visiblement il existe pour cela les MUTEX mais je n'ai pas très bien compris, je pensse que je vais chercher un peu de doc la dessus ), et d'autre part, il n'y aurait pas plus simple? Je me suis dis intuitivement que pour communiquer entre eux les progs avez besoin d'un point fixe ( le fichier ), mais je ne sais pas si c'est exact et s'il n'y a pas d'alternative plus simple voir plus sure a mettre en oeuvre.
Qu'en penssez vous ( et désolé pour le pavé )
Citation :
c/c d'un topic de OSA, qui a ptet plus ca place ici, a vous de me dire ...
|