non-bloquant (E/S pilotées par événement) vs E/S bloquantes

Question

Récemment, j'ai trébuché sur cette bibliothèque JS assez sophistiquée appelée nodeJS qui agit comme un serveur côté JS.

La caractéristique principale du langage étant E/S Evented qui donne la capacité inhérente d'E/S étant complètement non-bloquant en utilisant les callbacks !!! Ma question est la suivante: si ce type de mécanisme d'E/S complètement non bloquant existait dans le passé (étant donné que les E/S pilotées par événements existent depuis longtemps), pourquoi ne sont-ils pas plus populaires dans le haut niveau? des langages comme C# et Java (bien que Java ait une implémentation NIO qui supporte les E/S non bloquantes)? Actuellement, une simple opération de lecture/écriture de fichier entraîne un blocage complet des E/S, ce qui n'est pas le cas avec les E/S pilotées par événement. Je voudrais mieux comprendre les E/S pilotées par les événements et comment elles sont différentes de ce que nous avons en Java.

Answer 1

Java: http://en.wikipedia.org/wiki/New_I/O

Un multiplex, installation non bloquante E/S pour l'écriture des serveurs évolutifs

.NET: http://msdn.microsoft.com/en-us/library/dxkwh6zw.aspx

public IAsyncResult BeginReceive(
    byte[] buffer, 
    int offset, 
    int size, 
    SocketFlags socketFlags, 
    AsyncCallback callback, 
    Object state 
) 

Answer 2

Java a un mauvais support, même pour les E/S de fichiers de base. Ces langages sont créés pour la création rapide d'applications GUI portables, et non pour les opérations d'E/S de niveau bas optimisées et dépendantes du système d'exploitation.

Answer 3

Si je comprends bien, il y a une perception généralisée que le multithreading est plus facile que l'événement, puisque dans Programmation multithread Chaque thread a un flux d'exécution séquentiel simple, tandis que l'event-driven est constitué de nombreux petits fragments de code.

Bien sûr, cela est mieux indiqué ailleurs, voir par exemple Q.2 de state-threads FAQ.

Answer 4

Tcl avait des E/S pilotées par événements à partir des années 1990 (si je ne me trompe pas). Certainement avant 2000 parce que c'était quand tclhttpd battait Apache dans des tests d'évaluation en 2000 que les gens ont vraiment commencé à prêter attention aux E/S non bloquantes. Quand les gens ont vu cela, ils ont commencé à réécrire des serveurs Web. Lighttpd fut l'un des premiers résultats: un des premiers serveurs Web non bloquants écrits en C. À cette époque, l'utilisation d'E/S pilotées par événement dans tcl via la commande fileevent était déjà considérée comme une pratique standard dans le monde tcl.

AOLserver avait (et possède toujours) un noyau tcl et il héberge l'un des sites les plus fréquentés du web (au moins dans les premiers temps): http://www.aol.com/. Bien que le serveur lui-même soit écrit en C, il utilise l'API C de tcl pour implémenter la gestion des événements et les E/S. La raison pour laquelle AOLserver a utilisé le sous-système d'E/S de tcl est qu'il utilise tcl comme langage de script et les développeurs ont pensé que puisque quelqu'un d'autre l'avait écrit, il pourrait aussi bien l'utiliser. Je pense que AOLserver a été publié pour la première fois en 1995. Cela devrait confirmer que les E/S pilotées par les événements étaient déjà disponibles au milieu des années 1990.

Tcl est l'un des premiers, sinon le le premier langage à avoir un moteur piloté par les événements construit. Le sous-système d'événement a été implémenté à l'origine pour la bibliothèque Tk et a ensuite été fusionné avec tcl lui-même.