On est plutôt habitué dans nos développements à faire du synchrone: on appelle une fonction, elle retourne une valeur quand elle a fini de travailler. Avec Javascript ça peut être totalement différent, par exemple avec Node.JS:
var fs = require("fs"); fs.readFile("fichier.txt", function(err, content) { if (err) { console.err(err); } else { console.log("file read: " + content.length + " bytes"); } } console.log("after readFile");
En programmation synchrone, ce bout de code aurait lu le fichier, affiché « file read: X bytes » puis « after readFile ». Avec Node.JS ce n’est pas le cas, car toutes les fonctions systèmes ont une version synchrone (qui renvoie un résultat et lève une exception en cas d’erreur), et une vesion asynchrone (qui ne va rien renvoyer, rendre tout de suite la main, et prendre en paramètre un callback acceptant une éventuelle exception et le reste des paramètres).
Le retour attendu sera plutôt celui-là:
after readFile
file read: X bytes
La fonction a tout de suite rendu la main. Il devient ainsi totalement trivial de lire plusieurs fichiers en même temps, ou de réaliser n’importe quelles actions simultanément en mode asynchrone.
Mine de rien, ça change tout ! Et quand on fait du développement web, donc que la même application va devoir être capable de traiter pleins de requêtes différentes en même temps, l’asynchrone (et la gestion des contextes qui va avec) est tout-à-fait adapté: concrètement une requête un peu plus longue à traiter que les autres ne plombera absolument pas les requêtes d’à côté. C’est d’ailleurs il me semble le paradigme choisi par nginx, qui lui réussit plutôt bien
Hé mais pourquoi on n’a pas toujours fait comme ça, d’ailleurs ?

Comments:1
Laisser un commentaire