Je ne sais pas comment on fait, mais ça doit être possible:
Tu peux tenter de mettre un callback sur le retour de ta fonction, genre
la lancer avec pour instruction d'appeler telle fonction après le
retour. Ca me paraît plus élégant que d'aller tester sa terminaison avec
kill -0, qui de toute façon introduira une composante non-déterministe
dans ton algo. Quelque part tu es en train de faire des tests "en
aveugle" sur des processus qui sont pourtant sous ta main, ce qui n'est
pas très logique.
Après si tu veux aussi exécuter des actions après que tous tes threads
ont terminé, il te faudra une sorte de concentrateur, genre un tableau
qui note qui a terminé et un compteur d'occurences restantes. Voire une
limite de temps ou autre qui termine de force ceux qui ont bloqué.
Enfin à voir, tiens nous au courant.
TM
On 12/03/2013 12:40 PM, Vincent Riquer wrote:
> À 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.
>
