Bonjour,
 
Je suis en train de faire un petit shell. J'utilise pour cela un fork et la fonction execvp pour exécuter le programme. Lorsque mon programme est en cours d'exécution, mon shell est bloqué en attente du signal SIGCHLD (envoyé par son enfant). Je gère cette arrivée de signal à l'aide d'un traitant qui fait un loop grâce à des wait non bloquants (utile dans le cas où on a un pipe et plusieurs applis qui terminent en même temps et donc la possibilité de recevoir un seul SIGCHLD pour plusieurs morts).
 
Voici mon problème:
Je me mets en pause pour attendre le signal SIGCHLD qui va débloquer mon shell (le père). Le problème est que sur des pc modernes, la mise en pause, est plus longue que l'execution de certains programmes (genre ls) et donc le shell reçoit le signal SIGCHLD avant sa mise en pause. Il traite ce signal (donc le fils ne devient pas un zombie) mais malheureusement, le shell attend indéfiniment un signal permettant de le sortie du mode pause.
 
Est-ce qu'il y a moyen de résoudre ce problème ? La seule technique que j'ai trouvée est de faire un sleep avant le lancement de mon programme (donc vraiment pas une solution   ).
 
Voici le code du traitant du signal SIGCHILD.
 

Voici le code de la partie fork() + attente: (il y a aussi une gestion de la redirection dans le cas d'un pipe)
 

Au lieu de fork(), il existe vfork() qui peut être intéressant dans ce cas, car le processus père reste suspendu et il n'y pas besoin de faire une boucle d'attente de la fin du processus fils.
 
Edit: Oups, je vois que vfork() est deprecated (obsolète), mais que l'on peut utiliser posix_spawn() à la place.

ok merci,
 
effectivement, vfork() ou posix_spawn() mettent le processus père en pause mais sont quand même assez limité et ne font pas le même travail que fork().
 
de toute manière, je n'ai pas résolu ce problème et je pense que si on veut vraiment un appel bloquant efficace, on doit utiliser wait() et non pas pause().