Les subtilitées d' epoll suite

Bonjour,

Je suis entrain d'utiliser epoll dans une application client/serveur multiclients sur connexions tcp.

Je l'utilise en mode "classique" cad en mode level triggered..

J'aimerais savoir pourquoi, parfois, epoll m'indique un descripteur de socket prêt en lecture (EPOLLIN) alors que lorsque je fait un read sur le descripteur juste après, il n'y a rien a lire : read revoie donc 0...

Ceci se produit lorsque je détruis brutalement mon client avec un signal 15.
Je précise qu'a cet instant le client a déja ecrit sur la socket de son coté...

Pourquoi le read renvoie il 0 alors que epoll indique que le descripteur est prêt en lecture, normalement ne devrait on pas avoir des données a lire?

Je précise pour info que j'utilise la boucle locale pour les tests.

Si read te renvoie 0 sur une socket, ça veut dire qu'elle est déconnectée (c'est d'ailleurs de cette façon qu'on arrive à voir si le client est toujours connecté). Si tu tentes d'écrire sur une socket déconnectée, tu recevras le signal SIGPIPE sur unix.

EDIT: je précise que c'est dans le cas d'une socket bloquante (ce qui est le cas par défaut).

Merci imperio,

Ça veut donc dire que le client c'est déconnecté entre l'appel a epoll et read...
Sinon epoll aurait renvoyé EPPOLUP...

Ok, ça me parait plus clair maintenant.

Vois ça comme ça : ta socket a été déconnectée donc le statut en lecture a changé donc epoll se débloque. Il est très important par ailleurs d'être sûr d'écrire dans une socket connectée (comme je l'ai déjà dit dans mon précédent post). Mets le sujet en résolu si c'est bon.