2011-04-10 13 views

Respuesta

7

El contenido del enlace que publicó es correcto. Un socket de archivo regular, abierto en modo no bloqueante, siempre estará "listo" para leer; cuando realmente intentas leerlo, se producirá un bloqueo (o más exactamente como señala tu fuente, durmiendo) hasta que la operación pueda tener éxito.

En cualquier caso, creo que su origen necesita algunos sedantes. Una persona enojada, eso es.

+2

Solo me pareció ligeramente enojado. –

1

Usted es correcto que el modo no bloqueante no tiene ningún beneficio para los archivos normales, y no se le permite. Sería bueno si hubiera un indicador secundario que pudiera establecerse, junto con O_NONBLOCK, para cambiar esto, pero debido a la forma en que funciona el caché y la memoria virtual, en realidad no es una tarea fácil definir qué comportamiento correcto de "no bloqueo" para los archivos ordinarios significaría. Ciertamente habría condiciones de carrera a menos que permitiera a los programas bloquear la memoria asociada con el archivo. (De hecho, una forma de implementar una especie de IO no dormir para los archivos ordinarios sería mmap el archivo y mlock el mapa. Después de eso, en cualquier aplicación razonable, read y write nunca dormir, siempre y cuando el archivo de offset y el tamaño del búfer se mantuvo dentro de los límites de la región mapeada.)

+0

En cuanto a mmap() ... sería un bloqueo para convertir el archivo en no bloqueante ... ;-) –

+1

No es * que * difícil definir qué comportamiento sin bloqueo podría significar para los archivos comunes. El kernel debería señalar el archivo como listo para leer cuando los datos solicitados por la siguiente 'lectura 'se encuentran en la memoria caché de la página. Si se ha ido para entonces, el kernel podría simplemente devolver 'EWOULDBLOCK' (y agregar el rango solicitado a alguna captación previa obligatoria y cuando esté disponible, el archivo estará listo para leer, y así sucesivamente). No sería una condición de carrera si todos se implementan correctamente, pero existiría la posibilidad de un bloqueo en vivo si muchos procesos siguen intentándose superarse entre sí y ninguno progresa. – DepressedDaniel

4

He estado indagando bastante sobre esto durante las últimas horas y puedo atestiguar que el autor del enlace que ha citado es el correcto. Sin embargo, el soporte parece ser "mejor" (usando ese término muy vagamente) para non-blocking IO against regular files en Linux Kernel nativo para v2.6 +. El paquete "libaio" contiene una biblioteca que expone la funcionalidad ofrecida por el núcleo, pero tiene algunas advertencias sobre los diferentes tipos de sistemas de archivos que son compatibles y no es portátil para nada fuera de Linux 2.6+.

Y aquí es another good article sobre el tema.

Cuestiones relacionadas