e / S de archivos asincrónicos en búfer en linux

A menos que desee escribir su propio thread pool de IO, la implementación de glibc es una solución aceptable. En realidad, funciona sorprendentemente bien para algo que funciona completamente en Userland.

La implementación del kernel no funciona con IO en búfer en absoluto en mi experiencia (¡aunque he visto a otras personas decir lo contrario!). Lo cual está bien si desea leer grandes cantidades de datos a través de DMA, pero por supuesto es una mierda si planea aprovechar la caché de búfer.
También tenga en cuenta que las llamadas AIO del núcleo pueden bloquear. Hay un búfer de comandos de tamaño limitado, y las lecturas grandes se dividen en varias más pequeñas. Una vez que la cola está llena, los comandos asíncronos se ejecutan de forma sincrónica. Sorpresa. Me he encontrado con este problema hace un año o dos y no pude encontrar una explicación. Preguntar por ahí me dio la respuesta "sí, por supuesto, así es como funciona".
Por lo que he entendido, el interés "oficial" en apoyar a buffered aio tampoco es terriblemente grande, a pesar de varios las soluciones de trabajo parecen estar disponibles durante años. Algunos de los argumentos que he leído estaban en las líneas de " no quieres usar los buffers de todos modos "y" nadie necesita eso "y"la mayoría de la gente ni siquiera usa epoll todavía". Así que, bueno... meh.

Ser capaz de obtener una epoll señalada por una operación asincrónica completada era otro problema hasta hace poco, pero mientras tanto esto funciona muy bien a través de eventfd.

Tenga en cuenta que la implementación de glibc en realidad generará hilos bajo demanda dentro de __aio_enqueue_request. Probablemente no es gran cosa, ya que desovar hilos ya no es que terriblemente caro, pero uno debe ser consciente de ello. Si su comprensión de iniciar una operación asincrónica es "retorna inmediatamente", entonces esa suposición puede no ser cierta, porque puede estar generando algunos hilos primero.

EDIT :
Como nota lateral, bajo Windows existe una situación muy similar a la de la implementación de glibc AIO donde el " regresa inmediatamente" la suposición de poner en cola una operación asíncrona no es cierta.
Si todos los datos que desea leer están en la caché del búfer, Windows decidirá que en su lugar ejecutará la solicitud sincrónicamente, porque terminará inmediatamente de todos modos. Esto está bien documentado, y es cierto que suena genial, también. Excepto en caso de que haya unos pocos megabytes para copiar o en caso de que otro hilo tenga fallas de página o LO haga simultáneamente (compitiendo por el bloqueo) "inmediatamente" puede ser un sorprendentemente largo tiempo seen he visto tiempos "inmediatos" de 2-5 milisegundos. Lo cual no es un problema en la mayoría de las situaciones, pero por ejemplo bajo la restricción de un tiempo de fotograma de 16.66 ms, probablemente no desee arriesgarse a bloquear 5 ms en momentos aleatorios. Por lo tanto, la asunción ingenua de "puede hacer async IO desde mi hilo de renderizado no hay problema, porque async no bloquea" es defectuosa.