Discussion :

[rickou73]

Bonjour a tous !

je vous dresses un petit topo d'un projet sur lequel je bosse et pour lequel j'ai un petit pépin...

Je travaille sous linux en embarqué sur plateforme ARM. (Tegra 2)
je dois utiliser une LIB qui fait un traitement d'image. cette lib est développée en C++ et utilise OpenCV.
elle a les interfaces (qui me sont utiles) suivantes:
- en entrée je lui injecte des images issues d'un flux vidéo (~30 images / sec) via une methode de la classe principale.
- en entrée toujours, je lui injecte des paramètres divers de fonctionnement. (plus ou moins pendant une phase d'init)
- en sortie, je récupère régulièrement (~ttes les 10 minutes) une liste d'entiers résultants de l'analyse des images via des méthodes/fonctions de la classe principale et sous classes.

cette jolie LIB (statique pour le moment) a été clairement développée avec les pieds et plante lamentablement aléatoirement. (segmentation fault ou autres erreurs plus ou moins catchables) j'ai le source, mais pas le droit d'y modifier le moindre caractère.
bien évidement je ne peux pas me permettre de voir mon appli principale planter a cause de cette LIB (besoin que l'appli principale continue de tourner et de continuer ses autres acquisitions.

donc vu les segmentations Fault qui sont irrécupérables proprement, j'ai décidé de "sortir" l’exécution de la LIB dans un process indépendant afin de pour la relancer en cas de crash.

actuellement j'ai fait ça a l'aide d'un vfork() du thread dans lequel tourne la LIB. ça fonctionne assez bien, l'avantage étant que j'évite de faire de l'IPC grâce a la mémoire partagée entre le process principal et le process de ma LIB...
MAIS...
- j'ai lu un peu partout que le vfork est a bannir...
- j'utilise des mutex conditionnels pour synchroniser mon process LIB avec mon autre process qui gère l'acquisition et l'injection des images (actuellement le point commun entre l'acquisition et le la LIB se résume à un mutex conditionnel et une FIFO de buffer contenant les images.)
et le problème est que j'ai de façon TRES aléatoire des plantage de la LIBC au niveau des mutex conditionnels. (un truc qui a un rapport avec son propriétaire) ce qui provoque un ABORT dans mon appli principale.. ce qui n'est pas acceptable.

je voulais donc refaire cette partie du code afin de la rendre un peu plus "propre" et complètement sortir la LIB dans un autre programme 100% indépendant et utiliser un lien IPC quelconque entre les 2.

mon problème est que je ne sais pas quoi choisir comme moyen...
pipe ? shared memory ? autre ?
j'imaginais avec un lien genre "fichier" dans lequel je pourrais injecter des images ce qui déclencherai (a la fin du transfert) immédiatement l'injection dans la LIB et que le process soit en sleep le reste du temps.
et par ce même lien récupérer le résultats.

Quelqu'un peut il m'aider ? des exemples d'un truc similaire ?

j'oublais... mon appli est en C.. je préfère car j'ai beaucoup de mal de piger le C++

Merci a tous !

[schonai]

Bonjour,

j'imaginais avec un lien genre "fichier" dans lequel je pourrais injecter des images ce qui déclencherai (a la fin du transfert) immédiatement l'injection dans la LIB et que le process soit en sleep le reste du temps.

Je te conseil les pipes nommés. Contrairement aux autres IPCs dont l'API est à vomir les pipes nommés s'utilisent comme de simples fichiers à l’exception de la création. L'avantage est aussi que l'ouverture du fichier en lecture/écriture et bloquant tant qu'un processus n'ouvre pas le fichier en écriture/lecture. Une fois le fichier ouvert tu es donc certain qu'il y a quelqu'un au bout du fil. Je t'invite donc à regarder du côté de la fonction mkfifo et de cet excellent guide sur les IPCs

- en entrée je lui injecte des images issues d'un flux vidéo (~30 images / sec) via une methode de la classe principale.
- en entrée toujours, je lui injecte des paramètres divers de fonctionnement. (plus ou moins pendant une phase d'init)

Si tu as besoin de plusieurs input à des fréquences différentes (si c'est pas que pendant l'init) tu pourrais utiliser les fils de messages (cf le super guide) mais je pense que ça serait plus délicat à gérer.

[rickou73]

Je te conseil les pipes nommés. Contrairement aux autres IPCs dont l'API est à vomir les pipes nommés s'utilisent comme de simples fichiers à l’exception de la création. L'avantage est aussi que l'ouverture du fichier en lecture/écriture et bloquant tant qu'un processus n'ouvre pas le fichier en écriture/lecture. Une fois le fichier ouvert tu es donc certain qu'il y a quelqu'un au bout du fil. Je t'invite donc à regarder du côté de la fonction mkfifo et de cet excellent guide sur les IPCs

alors j'ai un peu regardé les pipes et FIFO.. la problématique est que le buffer est tout petit ! 4ko ou 65ko pour certains systemes, ce qui veut dire c'est que je n'ai aucune idée de la consistance de ce que j'aurai au niveau du recepteur sans y mettre une surcouche applicative de control des paquets...
a la base j'imaginais un truc du genre...
l'emetteur écrit un bloc (qui peut avoir une taille >>65ko et le recepteur recoit ce bloc en 1 morceau forcement. (transfert atomique en gros)
mais je pense que je ne vais pas louper de devoir faire un peu de "glue" autour de ces transferts...

Si tu as besoin de plusieurs input à des fréquences différentes (si c'est pas que pendant l'init) tu pourrais utiliser les fils de messages (cf le super guide) mais je pense que ça serait plus délicat à gérer.

ok, la il faut que je regardes, je ne connais pas... mais n'y a t il pas des problemes de pertes de messages possibles ?? j'ai besoin que les échanges soient sûrs... (hormis si mon 2nd process crash évidement..)

d'ailleurs comment gérer que ce fameux 2nd process puisses crasher a tout moment ?? qu'en est il des liaisons plus ou moins en cours ??

Merci en tout cas pour les liens, je vais y jeter un oeil de ce pas !

[schonai]

Pour la taille du pipe on peut toujours s'arranger :o Avec fcntl() tu peux changer la taille maximum des pipes. Après je trouve que c'est une pratique à éviter le plus possible.

Cette solution ne règle de toute façon pas ton problème de transfert atomique et pour le coup les message queues sont bien plus pratiques. Le transfert consiste seulement à rajouter un message dans la file.
En cas de crash tes données sont conservées, en effet la mémoire est gérée par le kernel et est persistante. Comme pour les pipes il y a une limite sur la taille des files de messages et comme pour les pipes tu peux la contourner avec msgctl(). Grâce à la lecture des messages par type tu pourras aussi différencier ton paramétrage de tes données.

[gangsoleil]

Bonjour,

Je ne me souviens plus si dlopen est capable de gerer les problemes de ta lib externe... Je dirai qu'a priori non, mais tu peux toujours regarder.

Sinon, tu peux utiliser fork(), et faire un wait() dans le code du père... Le comportement devrait être à peu près le même que vfork (sachant que je viens de lire le man, donc je ne connais pas bien cette fonction)

Sinon, il te reste tous les autres moyens de communication :
un segment de memoire partagee
un échange de données via fichier -- attention à bien gérer un sémaphore sur l'écriture du fichier si le second processus peut commencer à lire alors que le premier n'a pas fini d'écrire

Et enfin, tu n'as pas le droit de modifier la lib, soit, mais est-ce que la licence t'autorise à la cloner ? Si oui, tu fais un clone de la lib, et tu corriges ce que tu veux dedans (en gardant la même licence et tout et tout bien sur).

[rickou73]

Je ne me souviens plus si dlopen est capable de gerer les problemes de ta lib externe... Je dirai qu'a priori non, mais tu peux toujours regarder.

a priori non, de toutes façons de tout ce que j'ai pu lire a droite et a gauche (et c'est tout a fait compréhensible) une SegFault n'est pas récupérable... vis a vis au mini des allocations mémoire potentiellement a libérer..

Sinon, tu peux utiliser fork(), et faire un wait() dans le code du père... Le comportement devrait être à peu près le même que vfork (sachant que je viens de lire le man, donc je ne connais pas bien cette fonction)

oui j'ai commencé a tester.. mais la modif est lourde... et je dois obligatoirement passer par de l'IPC...
et je n'arrives pas a me décider a vrai dire... j'ai lu et relu bcp de choses notamment sur les messages queues dont m'a parlé schonai.. mais celà semble relativement gourmand en ressources avec des recopies sans cesse des buffers... et je travaille avec de la vidéo en entrée ! donc si je peux éviter les copies...mon "petit" CPU ne s'en portera pas plus mal ! ah oui car il tourne a environ 400MHz mon Tegra2 (problématiques de conso énergétique en prime !)

Sinon, il te reste tous les autres moyens de communication :
un segment de memoire partagee
un échange de données via fichier -- attention à bien gérer un sémaphore sur l'écriture du fichier si le second processus peut commencer à lire alors que le premier n'a pas fini d'écrire

oui j'ai dejà géré la chose pour récupérer mes images afin de les afficher en live sur une page Web via du CGI.. ça marche plutôt bien.. mais bon c'est une usine a gaz pour gérer des images complètes et pourtant ne rien bloquer de nul part pour assurer les 30fps du traitement...
mais je sens que je vais devoir y repasser... sic...

Et enfin, tu n'as pas le droit de modifier la lib, soit, mais est-ce que la licence t'autorise à la cloner ? Si oui, tu fais un clone de la lib, et tu corriges ce que tu veux dedans (en gardant la même licence et tout et tout bien sur).

en fait, c'est une lib sous licence fermée et la mise a dispo du code source a été fastidieuse et accompagnée d'un contrat béton car grosse propriété intellectuelle.. (c'est eux qui gèrent... mais vu la rapidité... je veux faire comme si je n'avais pas le choix) et a vrai dire.. je ne préfères pas y mettre le nez car pas assez calé notamment en traitement image.


Je pense que je vais sortir completement ma LIB sur un soft indépendant que je pourrais lancer et surveiller (via un fork + exec.. ? ou carement autre chose ??)
je partagerai les images via une mémoire partagée et liste de buffers le tout hebergé par l'appli principale.
la synchro... sémaphores ? je voudrais que l'appli "LIB" soit en Wait quand elle n'a pas de traitements a faire afin de consommer le moins de CPU possible..
(actuellement je travaille avec des variable conditionnelles... mais elles me posent problèmes aléatoirement...)

d'ailleurs, vaut-il mieux utiliser les fonctions du System V ou POSIX ?

je vous tiendrai au courant de mon avancement... j'espere demain.... oups...