Quelle activité d'ES le gestionnaire d'ES du GHC prend-il en charge?

Question

J'ai lu sur le nouveau gestionnaire d'E / S dans GHC, qui utilise des notifications d'événements asynchrones et évite les E / S de blocage pour atteindre un débit élevé.

Quelles activités d'E / S peuvent être gérées par le nouveau code d'E / S asynchrone? Lecture et écriture de fichiers et activité réseau? Accès à la base de données? Y a-t-il des types d'E / S où le gestionnaire doit recourir au blocage?

Answer 1

Tout descripteur de fichier qui peut être géré par l' epoll/kqueue est admissible. Les bibliothèques qui souhaitent asynchrone traitement de l'I/O de la nécessité de collaborer avec le gestionnaire d'e/S par

• faire des descripteurs de fichiers non-blocage, et
• l'appel de la threadWaitRead et threadWaitWrite fonctions en GHC.Conc avant de tenter à nouveau un appel système que précédemment retourné EWOULDBLOCK.

Cela a déjà été fait pour l' Handle et Socket types. Si vous utilisez par exemple une liaison à une C de la base de données de la bibliothèque, vous obtiendrez de blocage de comportement que celui de la bibliothèque de ne pas coopérer avec le gestionnaire d'e/S.

Answer 2

Un peu de réponse satisfaisante:

Le cœur de la nouvelle GHC IO manager est un kqueue()/epoll() boucle d'événements. Donc je m'attends à quelque chose qui peut être construit sur le dessus de cela pour être admissible, si ce n'est maintenant, puis, plus tard. Cela signifie en particulier:

• E / s de fichier
• Les e / s réseau

Le code (je l'ai regardé il y a quelques mois, et les choses ont peut être changé) contient également un soutien pour l'enregistrement et l'exécution de délais d'attente de plusieurs genres à travers une priorité (recherche) de la file d'attente. Cela suggère que la plupart des sleep-comme les appels peuvent également être se greffer sur l'interface.

À propos de l'Accès à la Base: bien sûr, vous avez souvent l'accès à la base de données à travers un réseau IO prise afin de l'appelant forkIO et en faisant DB accès dans un thread séparé devrait être faisable, rapide et sécurisé. La communication de données vers le reste de l'application peut être fait avec un de la simultanéité des moyens, Chan ou STM.TChan.

Je ne pense pas qu'il y a des genres de IO où le gestionnaire a recours à de blocage en soi, mais je peux imaginer que certaines bibliothèques peuvent contourner le nouveau gestionnaire d'e / s et aller directement à la jugulaire. Ils seront, bien sûr, de les bloquer.