Bonjour,
 
(Les 2 applications sont développées en C sous linux.)
 
Je suis confronté à un problème et je ne vois pas comment le résoudre. J'ai 2 applications distinctes (A et B) dont une que je n'ai pas écrite (A). J'ai besoin de faire de la synchronisation temporelle entre ces 2 applications de la facon suivante :
 
L'application A écrit dans un segment de mémoire partagée une image vidéo toutes les x ms , puis libère un sémaphore servant à la synchro.
 
L'application B a une boucle de dessin pour son interface, et dans une zone elle doit afficher en vignette l'image générée par l'application A. Pour se synchroniser à A , B se met en attente sur le sémaphore, et lorsqu'il est libéré par A, B dessine son interface, puis va lire dans le segment de mémoire partagée l'image générée par A et le dessine dans le reste de l'interface, puis B blitte à l'écran l'interface avec la vidéo.
 
Ceci fonctionne très bien sauf dans un cas : quand A plante brutalement. En effet, A est lancé par B via un fork, et on recoit bien l'info SIGCHILD lorsque A est bien quitté, mais pas lorsque A plante brutalement. La conséquence est que le thread de dessin de l'interface est bloqué, puisqu'en attente d'une libération de sémaphore, et B n'a absolument aucune info que A a quitté brutalement (hormis en mettant en place un chien de garde, mais ce n'est pas une bonne solution).
 
Sachant qu'il est indispensable de synchroniser de facon temporelle les 2 applications afin que les images soient affichées au bon cadencement (cadencement géré par A) puisqu'il s'agit d'une vidéo, je n'ai pas d'autre choix que d'utiliser un mécanisme de synchronisation temporelle à base de sémaphore pour transmettre ce cadencement vers B.  
 
Comment faire pour que B soit informé d'un plantage brutal de A (afin de désactiver la lecture de la mémoire partagée) ?
 
Merci d'avance  

J'aurais jure que SIGCHILD est envoye quelle que soit la maniere dont
les enfants meurent.  Tu es sur que tu n'as pas un autre probleme?

En fait si tu postionnes (dans le processus père) SIGCHLDà SIG_IGN, tu ne recevras pas le signal.
 
Une piste à explorer ?
 
Edit: tu peux remettre le comportement par défaut avec un appel du genre "signal(SIGCHLD, SIG_DFL)".

les signaux de base et la latence, pas glop

Tu te préoccupes beaucoup de la latence quand tu traites les cas d'erreurs comme un
process qui meurt de façon inoppinée?  Moi pas.

J'aurais pensé aussi que SIGCHLD est envoyé quand le fils meure. Sinon si tu peux modifier A, tu peux positioner le falg SEM_UNDO sur ton opération, de sorte qu'elle soit automatiquement défaite si ton fils meure. Autrement tu peux positioner un timeout dans le père au lieu d'attendre indéfiniment (semtimedop() au lieu de semop()).

Je vais regarder un peu plus en détail. Je vais d'ailleurs faire 2 applications minimalistes pour tester cela.  
 
Mon appel à wait sur l'application A est faite dans la fonction de réception du signal SIGCHLD. Or je ne recois pas ce signal, et dans la liste des processus, je constate bien que mon application A s'est terminée, mais reste dans l'état zombie.
 
 

Il me semble que l'application A (appelons la par son nom , il s'agit de VLC) fait un trap sur des signaux , je vais vérifier que SIGCHLD n'est pas "trappé".
 

Je ne savais pas que l'on pouvait faire un appel conditionné sur un sémaphore. Merci de l'info, je pense que je vais exploiter aussi cette piste (en plus de corriger le probleme avec SIGCHLD).

 
Ca me ferait peur a priori ce SEM_UNDO ici.  Quand c'est un lecteur qui l'utilise, ca va.  Quand c'est
celui qui modifie les donnees, on peut se retrouver avec des donnees inconsistantes et pas d'avertissement.