Discussion :

[rdtech]

bonjour,
j'ai un processus fils qui tourne en tache de fond. Je dois le tuer a un moment donne depuis le processus pere avec l'instruction kill en utilisant SIGTERM.
Le code du processus fils:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
int fd = open(.....);  //ligne serie
while(1)
{
    //acquisition de donnees qui peuvent durer quelques ms
    write(fd, donnees);
    sleep(1);
}
close(fd);

Je me pose la question: kill arrivant de facon totalement asynchrone, quelle garantie ai-je que mon processus fils se terminera correctement a la fin de son boulot et non pas au milieu d'une acquisition ou d'un write ou sans faire le close?
Les pages de man ne sont pas tres explicite a ce sujet. (je trouve...)
Merci.

[picodev]

Bonjour,

SIGTERM est un signal que tu peux intercepter, si tu le reçois tu peux «tranquillement» terminer proprement, ce n'est pas un SIGKILL.

[chrtophe]

La commande système kill envoi par défaut un SIGTERM au pid passé en paramètre (kill -9 pid enverra lui un SIGKILL).

La fonction C kill envoie le signal de ton choix au processus de ton choix.

Prototype :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
int kill(pid_t pid, int sig);

[Obsidian]

Je me pose la question: kill arrivant de facon totalement asynchrone, quelle garantie ai-je que mon processus fils se terminera correctement a la fin de son boulot et non pas au milieu d'une acquisition ou d'un write ou sans faire le close?
Les pages de man ne sont pas tres explicite a ce sujet. (je trouve...)
Merci.

À noter que la réception d'un signal, même intercepté à l'aide de signal() ou sigaction(), provoque en principe l'échec de l'appel système en cours qui ressort immédiatement (s'il n'est pas coincé dans un sommeil ininterruptible « D ») avec le code d'erreur approprié.

Normalement, un programme bien écrit ne devrait pas avoir besoin de s'en soucier, puisque la réception de ce signal est une cause d'échec comme une autre, causes qui doivent normalement être prises en charge de façon générale sans cibler un contexte particulier. Par contre, il est intéressant de savoir que cela va provoquer le retour prématuré de « sleep() », par exemple, dont on pourrait légitimement penser qu'il ne peut échouer. Cela va aussi être le cas en cas de lecture de l'entrée standard avec fgetc() ou autre. Quand on s'en sert pour lire par défaut le clavier de l'utilisateur, il faut garder à l'esprit qu'elle peut échouer comme la lecture d'un fichier et traiter EOF proprement (chose normalement systématique avec les fichiers, et nécessaire si l'on veut pouvoir sortir avec Ctrl+D).

Il est important de remarquer que dans la quasi-majorité des cas, à part avec SIGCHLD et SIGURG (et SIGWINCH sur BSD et Sun, selon la man page), un signal reçu tue le processus s'il n'est pas dûment intercepté. Les signaux ignorés par défaut, eux, le sont totalement et n'interrompent donc pas les appels systèmes en cours SAUF s'ils sont justement interceptés car il faut bien donner la main au handler du signal. Donc, dans les deux cas (Kill ou Ign), un signal intercepté fera quand même échouer l'appel système en cours. Si le processus est purement en mode user (en train d'exécuter des tâches dans son propre segment, par exemple en traitant ses données uniquement avec des pointeurs), la réception d'un signal intercepté n'a pas d'incidence a priori.

[dalfab]

Il est cependant possible de ne pas avoir cette interruption d'un appel système.
En créant un thread dédié, et en masquant tous les signaux gênant sur les autres threads. Quand le signal survient il interrompra le thread dédié et pour les autres il n'y aura pas d'interruption.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void handler(int leSignal){
}
int thread_appat( void* prm )  {
  sigset_t masque;
  sigemptyset( &masque );
  sigprocmask( SIG_SETMASK , &masque , NULL );
 
  struct sigaction pourSignal = { 0 };
  pourSignal.sa_handler = &handler;
  sigaction( SIGTERM , &pourSignal , NULL );
 
  for(;;)
     pause(); // pause sera interrompu, puis se remettra en attente
}

Bien sûr le handler du signal doit avoir été mis en place et cela ne fonctionne pas pour les trois signaux non interceptables (SIGKILL, SIGCONT et SIGSTOP).

[rdtech]

Merci à tous,
vos réponses sont dans mes notes persos.
Des fois je vous trouve encore plus pointus que les pages de man.