2009-05-13 9 views
7

En http://linux.die.net/man/2/select, en la sección ERRORES se menciona que la llamada del sistema de selección a veces puede configurar falsamente el FD y la llamada de lectura posterior devolverá 0. El texto describe uno de esos ejemplos (suma de comprobación incorrecta) pero supongo que también habría otras razones (de lo contrario, habrían solucionado esto).Notificación de preparación espuria para Seleccionar llamada del sistema

Cualquier idea sobre qué podría hacer la otra causa para que Select devuelva un FD preparado de forma espuria.

y esto se aplica a otros sistemas operativos también. Actualmente estoy preguntando por Linux.

sección pertinente para el enlace anterior:

En Linux, seleccione() puede informar de un descriptor de archivo toma como "listo para lectura", mientras que sin embargo un bloques leídos posteriores. Esto podría ocurrir en el caso de cuando los datos han llegado pero al examinarse tiene una suma de comprobación incorrecta y se descarta. Puede haber otras circunstancias en las que un descriptor de archivo se informa falsamente como listo. Por lo tanto, puede ser más seguro usar O_NONBLOCK en conectores que no deben bloquearse .

Respuesta

1

Esto no es exactamente una respuesta, pero mirando por encima de epoll, estos problemas parecen estar resueltos para ello.

Y si puedo confiar en this message en netdev, al menos trataron de arreglarlo en sondeo() y seleccionar() también (rompiendo otras cosas).

Por lo tanto, este error no parece ser relevante en un futuro previsible.

Cuestiones relacionadas