Bonjour,
j'ai deja plusieurs fois utilise l'appel systeme select() pour creer des applications reseaux non bloquantes. Je n'ai jamais eu a passer en troisieme parametre de select (fd_set *writefds) autre chose que le pointeur nul, sans que ca m'aie pose probleme. Mais maintenant je me pose la question, quel serait l'utilite de détecter les ecritures sur un set de sockets grace a select, puisque c'est au programmeur de décider quand écrire des donnees sur la socket, non? (contrairement aux lectures qui doivent etre gerees par select() pour eviter de bloquer le flux de donnees). Existe-t-il des cas ou on pourrait s'en servir? (et eventuellement du 4eme parametre, fd_set *exceptfds)
Merci d'avance

Le but n'est pas de détecter les ecritures, mais les fins d'écritures. Ca permet de ne pas balancer 40 Mo de données d'un coup aux sockets qui ne sauront pas les emettre sans cafouillage... On va plutôt émettre par blocs de 30 ou 40 ko, et envoyer la suite sur reception d'une information 'fin d'ecriture'.

Le parametre 'exceptfds' sert à demander un déblocage sur des evènements urgents (signaux 'hors bande') tels qu'un demande de deconnexion de la part du distant, un ctrl-C (crtl-break) distant etc.

Donc si j'ai bien compris, il y a une bufferisation des donnees lors de l'envoi sur la socket, a tel point que l'ecriture peut se faire apres l'execution de la routine d'ecriture (par exemple un write(2)), et se finir eventuellement pendant le select?
C'est dangereux de negliger ce phenomene pour des envois beacoup moins gros, comme des chaines de caractères de quelques dixaine d'octets (représentant un protocole de communication)?
Ce n'est pas bloquant d'envoyer la chaine d'un seul trait avec write(2), du moment qu'en face la lecture est non bloquante?

C'est equivalent a regarder si read(2) sur la socket a renvoye 0 (auquel cas le distant s'est deconnecte) ?
Merci

Absolument. Il y a suffisament de buffers pour qu'un bloc pas trop gros (30..40 ko) puisse (vu de l'utilisateur) être envoyé en une fois, mais si il est vraiment énorme, on va manger énormément de ressources brutalement (pic), et ces ressources ne sont pas forcément disponibles, d'où un 'écrètage' et les pertes de données qui s'en suivent (perdre des données en émission, fait le faire quand même...). Le mécanisme de régulation est fourni par select() avec les évènements "write'.

En pratique, aucun risque, mais en toute rigueur, il faudrait appelet select() après tout write() de façon a syncroniser le processus (emission 'blocante')

En face, on ne sait pas ce qu'il y a. Effectivement, une ecriture avec write() n'est pas blocante.

Vu! Je vais mettre tout ca en pratique. Merci encore

de la place sur le buffer d'envoi plus exactement

D'apres le papier http://www.linuxinfor.com/french/man2/select_tut.html (la seule documentation detaillee de select que jai pu trouver), la technique est d'utiliser un buffer de taille fixe (et raisonnablement petite) pour l'envoi des donnees, pour etre certain que l'écriture se passe bien. L'envoi ne doit etre fait que si les buffers internes sont prets (en utilisant la macro FD_ISSET comme d'habitude), apres l'appel a select (ce qui permet en plus de gerer lectures & ecritures avec un seul select) si j'ai bien compris.