À la bouffe, Xavier m'avait suggéré d'insérer un sleep 0.1 entre kill -0 et
wait, selon l'hypothèse que kill -0 retourne faux avant que le process soit
totalement détruit. Le traitement s'est bloqué à la 1149ème tâche, il va
falloir trouver autre chose…
On Wednesday 27 November 2013 22:21:33 Vincent Caron wrote:
> On 11/27/2013 01:53 PM, Vincent Riquer wrote:
> > Si vous avez des solutions, des idées d'autres tests à faire, ou juste si
> > vous avez déjà rencontré le même souci, je suis preneur.
>
> Ca ressemble à une race condition : si 'wait pid' s'exécute bien
> c'est que le PID existe bien à ce moment là, puis s'il bloque, c'est que
> le SIGCHLD qu'a généré la terminaison de ce process a été bloqué ou
> intercepté "ailleurs" entretemps (désolé de ne pas être plus précis).
Oui, mais normalement non, puisque si kill -0 retourne faux, c'est que le
processus n'existe plus, c'est du moins ce qu'explique
http://mywiki.wooledge.org/ProcessManagement#Doing_it_right
> Je peux proposer de transformer l'approche polling en 'événementiel'
> qui est moins sujet aux 'race conditions'.
C'était l'approche utilisée dans ma deuxième implémentation¹, mais cela ne
fonctionnait pas : j'utilise des tableaux, et mon signal-handler, tel qu'il
était écrit, ajoutait une valeur à un tableau. Derrière, bash appelait
malloc(), syscall interdit dans un signal-handler. Le message d'erreur était
assez décoratif :)
Je pourrais peut-être réessayer en préallouant ma case de tableau, à tester.
¹ la première implémentation utilisait des descripteurs de fichier pour
communiquer, mais peut-être ceux-ci étaient mal libérés vu que j'obtenais "too
many open files" assez rapidement.
