Wie funktioniert nicht blockierende IO in Javascript

Question

Ich lese, dass die JavaScript-Sprache hat Eigenschaften, die bei der Implementierung von nicht-blockierenden IO helfen, die zum Erfolg von Projekten wie node.js beiträgt. Meine Frage ist, was sind diese Eigenschaften und warum ist nicht blockierende IO schwieriger in anderen Sprachen zu implementieren?

Answer 1

Der Grund, warum Javascript manchmal als nicht blockierende E/A gekennzeichnet ist, liegt am Konzept der anonym definierten (eventbasierten) Funktionen. Node.js bezeichnet dies ausdrücklich als Argument dafür, warum JavaScript eine gute serverseitige Sprache ist. Dies ist jedoch nur eine halbe Wahrheit, da es technisch nicht blockierend ist, aber es wird weiterhin Code ausführen, während auf einen Rückruf von einer anonymen Callback/Ajax-Funktion gewartet wird. Ich bin mir nicht sicher, ob das das ist, was Sie lesen, aber eine Erklärung in einem Knoten tutorial ist:

"Die andere Methode, die von Node und einige extrem schnelle moderne Server wie Nginx und Thin genommen wird, ist zu Verwenden Sie einen einzelnen blockierungsfreien Thread mit einer Ereignisschleife, und dies ist der Punkt, an dem die Entscheidung für JavaScript wirklich gilt, da JavaScript für die Verwendung in einer auf Einzelschleifen basierenden Event-Loop-basierten Umgebung konzipiert wurde: der Browser Event-based Programmierung tot einfach: Sie rufen im Grunde nur eine Funktion, um eine Art von I/O durchzuführen und übergeben Sie eine Callback-Funktion und JavaScript erstellt automatisch eine Schließung, um sicherzustellen, dass der richtige Zustand erhalten bleibt, auch nachdem die aufrufende Funktion längst ist außer Reichweite geraten. "

Quelle: http://net.tutsplus.com/tutorials/javascript-ajax/this-time-youll-learn-node-js/

In Bezug auf Ihren Multithreading-Tag, Node.js und Javascript sind NICHT multithreaded, sie ein System von Verschlüssen verwenden Zustand zu erhalten, während für einen Rückruf warten. Daher sind sie NICHT vollständig nicht blockierend. Es gibt viele Szenarien, in denen eine Blockierung auftreten kann. Bei den meisten kleinen Implementierungen wird ein Entwickler jedoch nie auf eine Blockierungssituation stoßen.

siehe hier für möglich, Informationen darüber, warum node.js ist schlecht: http://teddziuba.com/2011/10/node-js-is-cancer.html (Link gebrochen)

und hier für eine rebuttle: http://rhyolight.posterous.com/nodejs-is-not-cancer (Link gebrochen)

Answer 2

Asynchrone Funktionen sind normalerweise ereignisbasiert in JavaScript, was bedeutet, dass Callback-Handler registriert werden. Ihr Code läuft nach der Registrierung weiter, wartet aber nicht auf das Ereignis - alles, was nach einem Ereignis getan werden muss, muss vom Handler aufgerufen werden. Ich hoffe, das sagt alles.

Natürlich gibt es Ausnahmen, wie window.alert/confirm/prompt in Browsern.

Answer 3

JavaScript selbst bietet keine nicht blockierenden IO. Die zugrunde liegenden Systemaufrufe, die node.js verwendet, führen die nicht blockierende E/A durch. Die erstklassigen Funktionen von JavaScript bedeuten, dass es einfach ist, Callbacks weiterzugeben, wenn IO abgeschlossen ist.

Andere Sprachen können nicht blockierende IO gut tun. node.js argumentiert nur, dass Callbacks es sehr einfach machen, über nicht blockierende Operationen nachzudenken und diese zu behandeln.

Ruby hat EventMachine, die Blöcke statt Funktionen übergibt. C kann nicht-blockierende IO mit Funktionszeigern machen, aber dann bekommt man keine Schließungen, also ist es ein bisschen mehr Schmerz.