non-blocking (ereignisgesteuerte E/A) vs. blockierende E/A

Question

Kürzlich stolperte ich über diese ziemlich glatte JS-Bibliothek mit dem Namen nodeJS, die sich wie eine serverseitige JS verhält.

Das Hauptmerkmal der Sprache ist die Evented-E/A, die die inhärente Fähigkeit von E/A bietet, durch Rückrufe vollständig blockierungsfrei zu sein !!!

Meine Frage ist, wenn diese Art von vollständig blockierungsfreien I/O-Mechanismus in der Vergangenheit (gegeben ereignisgesteuerte I/O gibt es schon seit langer Zeit), warum sind sie nicht beliebter in High-Level Sprachen wie C# und Java (obwohl Java über eine NIO-Implementierung verfügt, die nicht blockierende E/A unterstützt)?

Gegenwärtig führt eine einfache Lese-/Schreiboperation zu einer vollständigen E/A-Blockierung, was bei ereignisgesteuerten E/A nicht der Fall ist.

Ich möchte ein besseres Verständnis für ereignisgesteuerte I/O und wie es ist anders als das, was wir in Java haben.

Answer 1

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

Ein Multiplex, nicht blockierende E/A-Einrichtung für

skalierbare Server schreiben .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 hat schlechte Unterstützung sogar für grundlegende Datei-I/O. Diese Sprachen werden für die schnelle Erstellung tragbarer GUI-Anwendungen und nicht für optimierte und vom Betriebssystem abhängige I/O-Operationen auf niedriger Ebene erstellt.

Answer 3

Wie ich es verstehe, gibt es eine weit verbreitete Wahrnehmung, dass Multithreading ist einfacher als ereignisgesteuert, da in Multithread-Programmierung Jeder Thread hat einen einfachen sequenziellen Ablauf der Ausführung, während ereignisgesteuert aus vielen kleinen Code-Fragmenten besteht.

Natürlich ist dies an anderer Stelle besser gesagt, siehe zum Beispiel Q.2 von state-threads FAQ.

Answer 4

Tcl hatte ereignisgesteuerte I/O aus den 1990er Jahren (wenn ich mich nicht irre). Sicherlich vor 2000, weil es war, als tcltttpd im Jahr 2000 in Benchmark-Tests Apache überflügelte, dass die Leute wirklich auf nicht-blockierende I/O aufmerksam machten. Als die Leute das sahen, fingen sie an, Webserver neu zu schreiben. Eines der frühen Ergebnisse davon war Lighttpd: einer der ersten nicht blockierenden Webserver in C. Zu diesem Zeitpunkt wurde die Verwendung ereignisgesteuerter E/A in tcl über den Befehl fileevent bereits als Standardpraxis in der tcl-Welt betrachtet.

AOLserver hatte (und hat immer noch) einen tcl core und hostet eine der meistbesuchten Seiten im Internet (zumindest in den frühen Tagen): http://www.aol.com/. Obwohl der Server selbst in C geschrieben ist, verwendet er die C-API von tcl, um Ereignisbehandlung und E/A zu implementieren. Der Grund, warum AOLserver das I/O-Subsystem von tcl verwendet, ist, dass es tcl als Skriptsprache verwendet und die Entwickler dachten, dass es jemand anders verwenden könnte, der es geschrieben hat.

Ich glaube, AOLserver wurde erstmals im Jahr 1995 veröffentlicht. Das sollte bestätigen, dass ereignisgesteuerte I/O bereits Mitte der 1990er Jahre in tcl verfügbar war.

Tcl ist eine der frühesten, wenn nicht die früheste Sprache, um eine ereignisgesteuerte Maschine zu haben. Das Ereignis-Subsystem wurde ursprünglich für die Tk-Bibliothek implementiert und später in tcl selbst zusammengeführt.