Puede haber casos en los que se informa que un socket está listo pero en el momento en que lo verifica, cambia su estado.
Uno de los buenos ejemplos es aceptar conexiones. Cuando llega una nueva conexión, se informa que un zócalo de escucha está listo para su lectura. Cuando llegue el momento de llamar a accept, la otra parte podría cerrar la conexión antes de enviar algo y antes de llamar al accept
. Por supuesto, el manejo de este caso depende del sistema operativo, pero es posible que accept
simplemente bloquee hasta que se establezca una nueva conexión, lo que hará que nuestra aplicación espere un tiempo indefinido para evitar el procesamiento de otros zócalos. Si su toma de audición está en un modo sin bloqueo, esto no sucederá y obtendrá EWOULDBLOCK
o algún otro error, pero accept
no se bloqueará de todos modos.
Algunos núcleos solían tener (espero que se solucione ahora) un error interesante con UDP y select
. Cuando llega un datagrama, select
se activa con el socket con el datagrama marcado como listo para leer. La validación de la suma de comprobación del datagrama se pospone hasta que un código de usuario llame al recvfrom
(o alguna otra API capaz de recibir datagramas UDP). Cuando el código llama al recvfrom
y el código de validación detecta una discrepancia en la suma de comprobación, simplemente se descarta un datagrama y recvfrom
termina bloqueándose hasta que llega un siguiente datagrama. Uno de los parches que resuelve este problema (junto con la descripción del problema) se puede encontrar en here.
Aha, gracias por eso. :) – CaptainCodeman