Discussion :

[Bundy*Al]

Bonjour à tous,

Je suis sous Linux (Fedora 14).
Je réalise une application client/serveur TCP/IP.

Parfois coté client je reçois l'erreur "L’appel a été interrompu par un signal." sur select.

Pour contourner l'erreur je fais:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
...
else if (ret < 0)
{
      perror("select");
 
       if (errno == EINTR)
       {
             continue;
       }
 
       kill(Fils_Un, SIGINT);
       kill(Fils_Deux, SIGINT);
       exit(EXIT_FAILURE);   
}

Je ne pense pas que traiter l'erreur avec continue soit la bonne solution.

Pouvez-vous m'indiquer comment traiter efficacement cette erreur?
Est-il possible de connaitre le signal qui provoque cette erreur?
Faut-il utiliser sigaction avec SA_RESTART?

Merci d'avance.

[orfix]

Pouvez-vous m'indiquer comment traiter efficacement cette erreur?

Rappeler select() tout simplement.

Est-il possible de connaitre le signal qui provoque cette erreur?

Franchement je ne sais pas, mais ça changerait quoi ?

Faut-il utiliser sigaction avec SA_RESTART?

C'est une possibilité oui, tu peux aussi utiliser la macro TEMP_FAILURE_RETRY (ce n'est rien d'autre qu'une boucle englobant l'appel système que tu lui passes.

[Obsidian]

Bonsoir,

Je ne pense pas que traiter l'erreur avec continue soit la bonne solution. Pouvez-vous m'indiquer comment traiter efficacement cette erreur?

En fait, si. Mais d'une manière générale, tous les appels bloquants peuvent être interrompus par des signaux. Donc, il faut coder en conséquence. Étant donné que les appels systèmes bloquants qui ne peuvent échouer pour quelque raison que ce soit sont extrêmement rares, on peut ranger l'arrivée d'un signal dans la gestion des erreurs ordinaires.

Est-il possible de connaitre le signal qui provoque cette erreur?

… cela dit, visiblement, les appels systèmes ne sont interrompus qu'à partir du moment ou un gestionnaire de signal est invoqué. Apparemment, les signaux ignorés, par défaut ou avec SIG_IGN n'ont pas d'effet sur les appels système en cours. Et si un signal n'est ni ignoré ni pris en charge, il tue le processus.

Donc, en principe, tu sais forcément quel/quels signal/signaux a/ont été reçus puisque les gestionnaires concernés ont été invoqués.

Faut-il utiliser sigaction avec SA_RESTART?

Selon man 7 signal, un certain nombre d'appels système sont exclus du domaine de cette facilité, et select() en fait partie. Donc, la réponse est non, dans ce cas précis.

[orfix]

J'aurais dû préciser (comme l'a fait juste en haut Obsidian) que dans ce cas précis (un système GNU/Linux) select() retournera toujours EINTR si elle est interrompue et ceux sans tenir compte du drapeau SA_RESTART, mais sinon ce comportement est implementation-defined :

NAME
pselect, select - synchronous I/O multiplexing
<...>
[EINTR]
The function was interrupted before any of the selected events occurred and before the timeout interval expired.

If SA_RESTART has been set for the interrupting signal, it is implementation-defined whether the function restarts or returns with [EINTR].

[Bundy*Al]

Bonsoir,

J'en conclus donc que le mieux est de conserver la solution exposée dans mon premier post.

Merci à tous les 2 pour toutes ces infos.

A+