Pourquoi node.js asynchrone?

Personne n'a en fait demandé (de tous les "suggestions" je suis et aussi de la recherche avant que j'ai demandé ici).

Alors pourquoi est node.js asynchrone?

De ce que j'ai déduit après quelques recherches:

Langages comme PHP et Python sont les langages de script (je peux me tromper sur les langues, les langages de script), tandis que le JavaScript n'est pas. (Je suppose que cela provient du fait que JS ne compile pas?)

Node.js fonctionne sur un seul fil, tandis que les langages de script d'utiliser plusieurs threads.

Asynchrone signifie apatrides, et que la connexion est persistante, tout en synchrone est la (presque) en face.

Peut-être que la réponse se trouve quelque part indiqué ci-dessus, mais je ne suis pas encore sûr.

Ma deuxième et dernière question relative à ce sujet est: est-ce

Pourrait JavaScript être faite dans un langage synchrone?

PS. Je sais que certains d'entre vous se demanderont "pourquoi vous voulez faire de la JS synchrone?" dans vos réponses, mais la vérité est que je n'ai pas. Je ne fais que poser ce genre de questions parce que je suis sûr qu'il ya plus de gens que juste moi qui ai pensé à de telles questions.

  • Merci les gars. Toutes vos réponses étaient excellents et ajouter une valeur différente aux questions ci-dessus. Je ne votera pas toute seule et unique réponse que le meilleur, comme je crois que vous avez toutes vos réponses question à quelqu'un d'autre lecture de cette question.
InformationsquelleAutor Joe | 2013-07-12
  1. 56

    Node.js fonctionne sur un seul fil, tandis que les langages de script d'utiliser plusieurs threads.

    Pas techniquement. Node.js utilise plusieurs threads, mais un seul thread d'exécution. Les threads d'arrière-plan permettant de traiter IO de faire tous les asynchrones bonté de travail. Traiter avec des fils de manière efficace est une douleur royale, de sorte que la prochaine meilleure option consiste à exécuter dans une boucle si le code peut s'exécuter alors que les threads d'arrière-plan sont bloqués sur IO.

    Asynchrone signifie apatrides, et que la connexion est persistante, tout en synchrone est la (presque) en face.

    Pas nécessairement. Vous pouvez conserver un état dans un système asynchrone assez facilement. Par exemple, en Javascript, vous pouvez utiliser bind() pour lier un this à une fonction, ce qui permet de préserver l'état explicitement lorsque la fonction renvoie:

    function State() {
    //make sure that whenever doStuff is called it maintains its state
    this.doStuff = this.doStuff.bind(this);
}
State.prototype.doStuff = function () {
};

    Asynchrone signifie pas d'attente pour une opération à la fin, mais l'enregistrement d'un auditeur à la place. Cela arrive tout le temps dans d'autres langues, notamment tout ce qui doit accepter l'entrée de l'utilisateur. Par exemple, dans une IHM Java, vous n'avez pas de bloc d'attente pour l'utilisateur d'appuyer sur un bouton, mais vous enregistrer un écouteur avec le GUI.

    Ma deuxième et dernière question relative à ce sujet est: est-ce

    Pourrait JavaScript être faite dans un langage synchrone?

    Techniquement, toutes les langues sont synchrones, même Javascript. Cependant, Javascript fonctionne beaucoup mieux dans une conception asynchrone, car il a été conçu pour être mono-thread.

    Fondamentalement, il existe deux types de programmes:

    • CPU, - la seule façon de le faire aller plus vite est d'obtenir plus de temps PROCESSEUR
    • IO liés passe beaucoup de temps d'attente pour les données, un processeur plus rapide ne sera pas question

    Jeux vidéo, les machines et les compilateurs sont liées à l'UC, tandis que les serveurs web et les Interfaces graphiques sont généralement IO lié. Javascript est relativement lent (à cause de la complexité), donc il ne serait pas en mesure de rivaliser dans un CPU, scénario (faites-moi confiance, j'ai écrit ma juste part de CPU Javascript).

    Au lieu de coder en termes de classes et d'objets, Javascript se prête à de codage en termes de fonctions simples qui peuvent être enchaînés. Cela fonctionne très bien dans la conception asynchrone, parce que les algorithmes peuvent être écrites pour traiter les données au fur et à mesure qu'il arrive. IO (en particulier les e /s réseau) est très lent, donc il y a un peu de temps entre les paquets de données.

    Exemple

    Supposons que vous avez 1000 connexions en temps réel, chaque livrer un paquet à chaque milliseconde, et le traitement de chaque paquet 1 microseconde (très raisonnable). Supposons également que chaque connexion envoie 5 paquets.

    Dans un seul thread, application synchrone, chaque connexion seront traitées dans la série. Le temps total est (5*1 + 5*.001) * 1000 millisecondes, ou ~5005 millisecondes.

    Dans un seul thread, application asynchrone, chaque connexion seront traitées en parallèle. Puisque chaque paquet de 1 milliseconde, et le traitement de chaque paquet .001 millisecondes, nous pouvons traiter chaque connexion de paquets entre les paquets, donc notre formule devient: 1000*.001 + 5*1 millisecondes, ou ~6 millisecondes.

    La traditionnelle solution à ce problème était de créer plusieurs threads. Cela a résolu le IO problème, mais lorsque le nombre de connexions a augmenté, l'utilisation de la mémoire (threads coût de beaucoup de mémoire) et d'utilisation de l'UC (multiplexage 100 threads sur 1 cœur est plus dur que le 1 fil sur 1 core).

    Cependant, il y a des inconvénients. Si votre application web se trouve également besoin de faire quelques lourds calculs, vous êtes SOL parce que pendant que vous êtes à croquer des nombres, des connexions besoin d'attendre. Filetage résout ce parce que l'OS peut échanger votre CPU-intensive tâche lorsque les données sont prêtes pour un thread en attente sur IO. Aussi, node.js est lié à un seul noyau, de sorte que vous ne pouvez pas profiter de votre processeur multi-core, sauf si vous faites tourner plusieurs instances et des demandes de proxy.

    InformationsquelleAutor beatgammit
  2. 32

    Javascript ne compile pas en quoi que ce soit. C'est "évalué" au moment de l'exécution, tout comme PHP & Ruby. Par conséquent, il est un langage de script comme PHP/Ruby. (c'est le nom officiel est en fait ECMAScript).

    Le "modèle" qui adhère aux est un peu différente de PHP/Ruby. Node.js utilise une "boucle" (le seul thread) qui a le seul but de prendre des demandes de réseau et de les manipuler très rapidement, et si, pour une raison quelconque, il rencontre une opération qui prend un certain temps (API demande, requête de base de données -- en gros tout ce qui concernait l'I. O. (entrée/sortie)), il passe d'un arrière-plan de "travailleur" thread et va faire autre chose pendant que le thread de travail attend le long de la tâche à accomplir. Quand cela arrive, le principal événement de la boucle " prendront les résultats et de continuer à traiter avec eux.

    PHP/Ruby suivant un modèle de thread. Essentiellement, pour chaque réseau entrantes demande, le serveur d'application tourne un isloated thread ou processus pour traiter la demande. Ce n'est pas formidablement bien et le Nœud de l'approche est souvent citée comme l'un de ses points forts par rapport à ce modèle.

    Asynchrone signifie apatrides, et que la connexion est persistante
    tout en synchrone est la (presque) en face.

    Pas. Synchrone instructions sont accomplies dans un ordre naturel, de la première à la dernière. Asynchrone instructions de dire que si une étape dans le flux d'un programme prend un temps relativement long, le programme continuera d'exécution des opérations, et il suffit de retourner à cette opération lorsque vous avez terminé.

    Pourrait JavaScript être faite dans un langage synchrone?

    Certaines opérations en JavaScript sont synchrones. D'autres sont asynchrones.
    Par exemple:


    Opérations de blocage:

    for(var k = 0; k < 1; k = k - 1;){
  alert('this will quickly get annoying and the loop will block execution')
alert('this is blocked and will never happen because the above loop is infinite');

    Asynchrone:

    jQuery.get('/foo', function (result) { alert('This will occur 2nd, asynchronously'); });
alert('This will occur 1st. The above operation was skipped over and execution continued until the above operation completes.');
    • le Javascript ne compile pas en quoi que ce soit. c'est faux. Node.js utilise V8 qui comprend un compilateur JIT qui compile en Javascript en code machine. Pour PHP, il ya beaucoup de solutions qui permet de compiler le code. Ruby n'évalue pas le code source, mais s'exécute sur un arbre de syntaxe abstraite. -> Le langage lui-même n'implique pas si il est interprété ou compilé, mais la mise en œuvre concrète de la question n'est pas interprétée dans un sens classique du terme.
    • il est compilé en byte code, pas du code machine.
    • compile le code source JavaScript directement dans le code machine quand il est exécuté. Il n'y a aucun intermédiaire d'octets de codes, pas d'interprète." Voir le v8 conception docs -> Dynamique de la Machine de Génération de Code
    • JS ne compile pas, pas plus que PHP ou Python. V8 est un super moment de l'exécution, mais vous donner script en texte brut, pas un binaire compilé.
    • Il se comporte comme un interprète, mais il a fonctionné à la manière d'un compilateur et est généralement appelé JIT compilateur. C'est un peu une zone grise, mais je pense que le qualifiant de "compilation" n'est pas injustifiée.
    • Mon point était que tout JIT langage compilé a la même propriété, de sorte qu'ils sont soit encore tous les langages de script, ou ils ne le sont pas. Considérant qu'un compilateur JIT peut être écrite pour à peu près n'importe quelle langue, que cela signifierait langages de script n'existent plus? Ou est-il autre chose pour elle? Cela est horriblement sémantique, mais mon point est que le fonctionnement interne de la V8 ne met pas le JS dans une classe différente de celle de PHP et Ruby.
    • De son mieux penser interprété et compilé des mises en œuvre, puisque les langues peuvent en avoir plusieurs. Si quelqu'un écrit un très compilateur rapide pour PHP en quelque sorte, la langue est toujours le même. Donc je suppose que je suis d'accord que l'ajout d'un nouveau compilateur n'a pas re-catégoriser une langue, mais pas parce que les compilateurs JIT ne sont pas de vrais compilateurs.

    InformationsquelleAutor Casey Flynn
  3. 20

    Pourrait JavaScript être faite dans un langage synchrone?

    Javascript n'est pas une "asynchrone de la langue"; plutôt, node.js a beaucoup de moteurs asynchrones Api. Asynchrone-ness est une propriété de l'API, et de ne pas la langue. La facilité avec laquelle les fonctions peuvent être créés et distribués en javascript, il est commode de passer des fonctions de rappel, ce qui est une façon de gérer le contrôle de flux dans une API asynchrone, mais il n'y a rien d'intrinsèquement asynchrone sur javascript. Javascript peut facilement prendre en charge synchrone Api.

    Pourquoi node.js asynchrone?

    Node.js faveurs des Api asynchrones parce qu'il est mono-thread. Ce système permet de gérer efficacement ses ressources propres, mais exige que les opérations de longue durée non-blocage, et des Api asynchrones sont une manière de permettre le contrôle de flux, avec beaucoup de non-blocage des opérations.

    InformationsquelleAutor Trevor Dixon