Me gustaría saber si el siguiente escenario es real ?!select(), recv() y EWOULDBLOCK en sockets sin bloqueo
Soy consciente de un error en un operativo de escritorio popular donde O_NONBLOCK sockets TCP, en particular los que se ejecuta sobre la interfaz de bucle de retorno, a veces pueden volver EAGAIN de recv() después select() informes el zócalo esté listo para la lectura. En mi caso, esto sucede después de que el otro lado cierra a medias el flujo de envío.
Para obtener más información, consulte el código fuente t_nx.ml en la biblioteca NX de mi distribución de entorno de aplicación de red OCaml. (link)
Es posible, pero solo en una situación donde tienes múltiples hilos/procesos tratando de leer desde el mismo socket.
Me alegra oír eso. Mi aplicación es de un solo hilo, así que estoy bien. – mrvincenzo
Para recv() obtendría EAGAIN en lugar de EWOULDBLOCK, y sí es posible. Ya que sólo se ha comprobado con select() entonces una de dos cosas sucedieron:
select() y recv().En caso de tiempo de espera, select() devuelve 0, por lo que no me preocupa. – mrvincenzo
#define EWOULDBLOCK EAGAIN/* La operación bloquearía */- se encuentra en muchos sistemas operativos – blaze
POSIX.1-2001 permite que se devuelvan errores al leer en un socket no bloqueante (y no requiere que tengan el mismo valor.) –
Es posible en un entorno multiproceso donde dos hilos están leyendo desde el zócalo. ¿Es esta una aplicación multiproceso?
Es una aplicación de un solo hilo. – mrvincenzo
Incluso si hay un tiempo de espera en el socket en lugar de solo un parámetro para 'select()'? ¿Qué pasa si el tiempo de espera ocurre entre 'select()' y 'recv()'? – dwc
En este caso, no debería ver este comportamiento. – mikelong
Si no llama a ningún otro syscall entre select() y recv() en este conector, entonces recv() nunca devolverá EAGAIN o EWOULDBLOCK.
No sé lo que significan con recv-timeout, sin embargo, el estándar POSIX no lo menciona aquí por lo que puede estar seguro llamando a recv().
Aunque mi aplicación es de un solo subproceso, noté que el comportamiento descrito no es raro en RHEL5. Ambos con sockets TCP y UDP que se establecieron en O_NONBLOCK (la única opción de socket que se establece). select() informa que el socket está listo, pero el siguiente recv() devuelve EAGAIN.
En Linux, incluso está documentado que esto puede suceder, mientras lo leo.
Ver esta pregunta:
El enlace parece estar roto – Thomas
Es curioso, en el menú de edición, se puede hacer clic en él. :RE – thejh