¿Qué actividad de IO admite el administrador de IH de GHC?

Question

He estado leyendo sobre el nuevo administrador de IO en GHC, que utiliza notificaciones de eventos asíncronas y evita el bloqueo de E/S para lograr un alto rendimiento.

¿Qué actividades de E/S son elegibles para la gestión mediante el nuevo código IO asíncrono? ¿Lectura y escritura de archivos y actividad de la red? Acceso a la base de datos ¿Hay tipos de IO en los que el administrador tiene que recurrir al bloqueo?

Answer 1

Cualquier descriptor de archivo que pueda ser administrado por epoll/kqueue es elegible. Las bibliotecas que deseen un tratamiento asíncrono de E/S tienen que cooperar con el administrador de E/S por

• hacer descriptores de archivos sin bloqueo, y
• llamando a los threadWaitRead y threadWaitWrite funciones en GHC.Conc antes de volver a intentar una llamada al sistema que previamente devuelto EWOULDBLOCK.

Esto ya se ha hecho por los HandleSocket y tipos. Si usa, p. un enlace a una biblioteca de base de datos C le dará un comportamiento de bloqueo ya que esa biblioteca no cooperará con el administrador de E/S.

Answer 2

Una respuesta un tanto satisfactoria:

El corazón del nuevo gestor de GHC IO es un bucle kqueue()/epoll() evento. Por lo tanto, esperaría que todo lo que se puede construir además de esto sea elegible, si no ahora, luego. En particular, esto significa:

• archivo IO
• Red IO

El código (lo miraba hace unos meses y las cosas podrían haber cambiado) también contiene soporte para el registro y corriendo los tiempos de espera de varios tipos a través de una cola de prioridad (búsqueda). Esto sugiere que la mayoría de las llamadas similares a sleep también pueden estar colándose en la interfaz.

Acerca del acceso a la base de datos: seguro, a menudo accede a la base de datos a través de un conector IO de red, por lo que llamar al forkIO y acceder a bases de datos en un hilo separado debe ser posible, rápido y seguro. La comunicación de datos al resto de la aplicación se puede hacer con uno de los medios de simultaneidad, Chan o STM.TChan.

No creo que haya tipos de IO en los que el administrador tenga que recurrir al bloqueo per se, pero me imagino que algunas bibliotecas pueden eludir al nuevo administrador de IO e ir directamente a la yugular. Ellos, por supuesto, bloquearán.