Connexion a un socket lors d'un signal ALRM

Robert a écrit:

Bonjour à tous,

J'ai écrit un programme qui joue le rôle de serveur pour d'autres
programmes.

Ce programme créé un socket TCP et se met en listen dessus puis att end
son premier client sur la fonction accept().

pas du C et encore moins du C++, ça devrait avoir sa place dans
fr.comp.os.unix

Comment y remedier ?

while (s = accept() == -1 && EINTR == errno);

je te donne l'explication et la solution propre quand je vois un post là
où il faut :)

"Robert" <robert@sansadresse.com> a écrit dans le message de
news:3f94f189$0$27029$626a54ce@news.free.fr...

Bonjour à tous,

J'ai écrit un programme qui joue le rôle de serveur pour d'autres
programmes.

Ce programme créé un socket TCP et se met en listen dessus puis attend
son premier client sur la fonction accept().

En meme temps, je souhaite tracer dans un fichier de log plusieurs infos
du serveur a intervalle regulier. J'utilise alors la fonction alarm()
pour gerer l'envoi d'un signal SIGALRM vers le process, que je catche et
que je traite.

Or une fois le premier signal SIGALRM recu et bien traité par le
handler, le programme continue au dela de la fonction accept() comme si
un client s'etait connecté...

Comment cela se fait que la reception de ce SIGALRM viennent debloquer
l'attente sur le accept() (bien evidemment aucun client ne se connecte) ?

Comment y remedier ?

Merci de vos tuyaux.

R.

Bonjour,

Je pense que ce message est hors sujet ici, mais je vais essayer d'y
répondre.

Tout d'abord, je suppose que ce programme fonctionne sous un UNIX (accept,
SIGALRM...)

Le comportement est normal, un signal interrompt toujours l'appel système en
cours.

Il y a deux façons de s'en tirer (selon l'UNIX utilisé)

- Dans le handler de signal, la structure passée en paramètre comporte
peut-être un champ qu'il faut modifier dans le handler pour indiquer que
l'on souhaite que l'appel système en cours soit relancé au lien d'être
interrompu.

- Après le accept, il est possible de vérifier le code retour (ou la liste
des file descriptors rendue) pour savoir si l'on a été interrompu ou si un
client s'est connecté. Dans le cas où on est interrompu, il suffit de
relancer l'accept.

Désolé de ne pas être plus précis, mais je n'ai pas de machine UNIX sous la
main en ce moment.

Rémy

Bonjour à tous,

J'ai écrit un programme qui joue le rôle de serveur pour d'autres
programmes.

Ce programme créé un socket TCP et se met en listen dessus puis attend
son premier client sur la fonction accept().

En meme temps, je souhaite tracer dans un fichier de log plusieurs infos
du serveur a intervalle regulier. J'utilise alors la fonction alarm()
pour gerer l'envoi d'un signal SIGALRM vers le process, que je catche et
que je traite.

Or une fois le premier signal SIGALRM recu et bien traité par le
handler, le programme continue au dela de la fonction accept() comme si
un client s'etait connecté...

Comment cela se fait que la reception de ce SIGALRM viennent debloquer
l'attente sur le accept() (bien evidemment aucun client ne se connecte) ?

Tu auras des réponses plus adaptées sur un forum UNIX.
fr.comp.os.unix

<HS>

1) En général, la réception d'un Signal interrompt les appels aux fonctions
système.
La fonction sort en erreur er 'errno' vaut EINTR.
Tu peux donc reboucler dans ce cas.

2) Sur certains systèmes, il est possible de configurer la gestion des signaux
pour que la fonction système ne s'arrête pas après traitement du signal.

3) Pour ce que tu fais, tu pourrais utiliser select() pour detecter la reception
d'un appel entrant avec TimeOut, et de faire ton traitement périodique en cas de
TimeOut.
ca évitera l'utilisation de signaux.

</HS>

Désolé, c'est HS et à la bourre, mais c'est select() que tu cherches.
(Et vive le man ;)

Gourgou