Pourquoi JavaScript ne prend-il pas en charge le multithreading ?

Question

Est-ce une décision de conception délibérée ou un problème avec nos navigateurs actuels qui sera corrigé dans les prochaines versions ?

Answer 1

JavaScript ne prend pas en charge le multithreading car l'interpréteur JavaScript du navigateur est un seul thread (AFAIK).Même Google Chrome ne permettra pas au JavaScript d’une seule page Web de s’exécuter simultanément, car cela entraînerait d’énormes problèmes de concurrence dans les pages Web existantes.Tout ce que Chrome fait, c'est séparer plusieurs composants (différents onglets, plug-ins, etc.) en processus distincts, mais je ne peux pas imaginer qu'une seule page ait plus d'un fil JavaScript.

Vous pouvez cependant utiliser, comme cela a été suggéré, setTimeout pour permettre une sorte de planification et de « fausse » concurrence.Cela amène le navigateur à reprendre le contrôle du thread de rendu et à démarrer le code JavaScript fourni à setTimeout après le nombre de millisecondes donné.Ceci est très utile si vous souhaitez permettre à la fenêtre (ce que vous voyez) de s'actualiser lors de l'exécution d'opérations dessus.Il suffit de parcourir par ex.les coordonnées et la mise à jour d'un élément en conséquence vous permettront simplement de voir les positions de début et de fin, et rien entre les deux.

Nous utilisons une bibliothèque d'abstraction en JavaScript qui nous permet de créer des processus et des threads qui sont tous gérés par le même interpréteur JavaScript.Cela nous permet d'exécuter des actions de la manière suivante :

• Processus A, fil 1
• Processus A, fil 2
• Processus B, fil 1
• Processus A, fil 3
• Processus A, fil 4
• Processus B, fil 2
• Suspendre le processus A
• Processus B, fil 3
• Processus B, fil 4
• Processus B, fil 5
• Démarrer le processus A
• Processus A, fil 5

Cela permet une certaine forme de planification et simule le parallélisme, le démarrage et l'arrêt des threads, etc., mais ce ne sera pas un véritable multithreading.Je ne pense pas que cela sera un jour implémenté dans le langage lui-même, car le véritable multithreading n'est utile que si le navigateur peut exécuter une seule page multithread (ou même plus d'un cœur), et les difficultés y sont bien plus grandes. que les possibilités supplémentaires.

Pour l'avenir de JavaScript, consultez ceci :https://developer.mozilla.org/presentations/xtech2006/javascript/

Answer 2

Traditionnellement, JS était destiné à des morceaux de code courts et rapides.Si vous aviez des calculs majeurs en cours, vous les faisiez sur un serveur - l'idée d'un JS+HTML application qui fonctionnait dans votre navigateur pendant de longues périodes pour faire des choses non triviales était absurde.

Bien sûr, nous l’avons maintenant.Mais il faudra un certain temps aux navigateurs pour rattraper leur retard – la plupart d’entre eux ont été conçus autour d’un modèle monothread, et changer cela n’est pas facile.Google Gears évite de nombreux problèmes potentiels en exigeant que l'exécution en arrière-plan soit isolée - pas de modification du DOM (puisque ce n'est pas thread-safe), pas d'accès aux objets créés par le thread principal (idem).Bien que restrictive, cette conception sera probablement la plus pratique dans un avenir proche, à la fois parce qu'elle simplifie la conception du navigateur et parce qu'elle réduit le risque lié au fait de permettre à des codeurs JS inexpérimentés de jouer avec les threads...

@marcio:

Pourquoi est-ce une raison pour ne pas implémenter le multi-threading en Javascript ?Les programmeurs peuvent faire ce qu’ils veulent avec les outils dont ils disposent.

Alors ne leur donnons pas des outils si faciles à utiliser abuser que tous les autres sites Web que j'ouvre finissent par planter mon navigateur.Une implémentation naïve de cela vous amènerait directement sur le territoire qui a causé tant de maux de tête à MS lors du développement d'IE7 :Les auteurs de modules complémentaires ont joué vite et librement avec le modèle de thread, ce qui a entraîné des bogues cachés qui sont devenus évidents lorsque les cycles de vie des objets ont changé sur le thread principal.MAUVAIS.Si vous écrivez des modules complémentaires ActiveX multithread pour IE, je suppose que cela fait partie du territoire ;cela ne veut pas dire qu’il faut aller plus loin que cela.

Answer 3

Le multithreading JavaScript (avec quelques limitations) est ici.Google a implémenté des Workers pour Gears, et les Workers sont inclus avec HTML5.La plupart des navigateurs ont déjà ajouté la prise en charge de cette fonctionnalité.

La sécurité des threads des données est garantie car toutes les données communiquées vers/depuis le travailleur sont sérialisées/copiées.

Pour plus d'informations, lisez :

http://www.whatwg.org/specs/web-workers/current-work/

http://ejohn.org/blog/web-workers/

Answer 4

Je ne connais pas la justification de cette décision, mais je sais que vous pouvez simuler certains des avantages de la programmation multithread en utilisant setTimeout.Vous pouvez donner l’illusion de plusieurs processus faisant des choses en même temps, même si en réalité, tout se passe dans un seul thread.

Demandez simplement à votre fonction de faire un peu de travail, puis appelez quelque chose comme :

setTimeout(function () {
    ... do the rest of the work...
}, 0);

Et toutes les autres choses à faire (comme les mises à jour de l'interface utilisateur, les images animées, etc.) se produiront lorsqu'ils en auront l'occasion.

Answer 5

Multithread.js encapsule les Web Workers et permet un multithreading facile dans JS.Fonctionne sur tous les nouveaux navigateurs, y compris iOS Safari.:)

Answer 6

Voulez-vous dire pourquoi le langage ne prend-il pas en charge le multithreading ou pourquoi les moteurs JavaScript des navigateurs ne prennent-ils pas en charge le multithreading ?

La réponse à la première question est que JavaScript dans le navigateur est censé être exécuté dans un bac à sable et de manière indépendante de la machine/du système d'exploitation, ajouter la prise en charge du multithreading compliquerait le langage et le lierait trop étroitement au système d'exploitation.

Answer 7

Comme l'a dit Matt B, la question n'est pas très claire.En supposant que vous posez des questions sur la prise en charge du multithreading dans le langage :car il n'est pas nécessaire pour 99,999 % des applications exécutées actuellement dans le navigateur.Si vous en avez vraiment besoin, il existe des solutions de contournement (comme utiliser window.setTimeout).

En général, le multithreading est très, très, très, très, très, très difficile (ai-je dit que c'est difficile ?) à réaliser correctement, à moins que vous n'appliquiez des restrictions supplémentaires (comme utiliser uniquement des données immuables).

Answer 8

Intel a effectué des recherches open source sur le multithreading en Javascript, elles ont été présentées récemment lors de la GDC 2012.Voici le lien pour le vidéo.Le groupe de recherche a utilisé OpenCL, qui se concentre principalement sur les jeux de puces Intel et le système d'exploitation Windows.Le projet porte le nom de code RiverTrail et le code est disponible sur GitHub

Quelques liens plus utiles :

Construire une autoroute informatique pour les applications Web

Answer 9

Actuellement, certains navigateurs prennent en charge le multithreading.Donc, si vous en avez besoin, vous pouvez utiliser des bibliothèques spécifiques.Par exemple, consultez les matériaux suivants :

• https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers(prend en charge les fils de discussion en arrière-plan) ;

• https://keithwhor.github.io/multithread.js/ (la bibliothèque).

Answer 10

Node.js 10.5+ prend en charge fils de travail comme fonctionnalité expérimentale (vous pouvez l'utiliser avec --travailleur-expérimental drapeau activé): https://nodejs.org/api/worker_threads.html

La règle est donc :

• si tu dois faire Opérations liées aux E/S, puis utilisez le mécanisme interne (alias callback/promise/async-await)
• si tu dois faire Opérations liées au processeur, puis utilisez les threads de travail.

Les threads de travail sont destinés à être des threads de longue durée, ce qui signifie que vous créez un thread en arrière-plan, puis vous communiquez avec lui via la transmission de messages.

Sinon, si vous devez exécuter une charge CPU importante avec une fonction anonyme, vous pouvez utiliser https://github.com/wilk/microjob, une petite bibliothèque construite autour de threads de travail.

Answer 11

Ce sont les implémentations qui ne prennent pas en charge le multithreading.Actuellement, Google Gears propose un moyen d'utiliser une certaine forme de concurrence en exécutant des processus externes, mais c'est tout.

Le nouveau navigateur que Google est censé lancer aujourd'hui (Google Chrome) exécute du code en parallèle en le séparant au cours du processus.

Le langage de base, bien sûr, peut avoir le même support que, par exemple, Java, mais le support de quelque chose comme la concurrence d'Erlang est loin d'être à l'horizon.

Answer 12

D'après ce que j'ai entendu, Google Chrome aura du javascript multithread, il s'agit donc d'un problème de "implémentations actuelles".

Answer 13

Selon Cet article il est déjà possible d'implémenter le threading JavaScript.

Answer 14

Sans une prise en charge linguistique appropriée pour la synchronisation des threads, cela n'a même pas de sens d'essayer de nouvelles implémentations.Applications JS complexes existantes (par ex.tout ce qui utilise ExtJS) planterait très probablement de manière inattendue, mais sans synchronized mot-clé ou quelque chose de similaire, il serait également très difficile, voire impossible, d'écrire de nouveaux programmes qui se comportent correctement.

Answer 15

Cependant, vous pouvez utiliser la fonction eval pour apporter la concurrence DANS UNE CERTAINE MESURE

/* content of the threads to be run */
var threads = [
        [
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');",
            "document.write('Foo <br/>');"
        ],
        [
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');",
            "document.write('Bar <br/>');"
        ]
    ];

window.onload = function() {
    var lines = 0, quantum = 3, max = 0;

    /* get the longer thread length */
    for(var i=0; i<threads.length; i++) {
        if(max < threads[i].length) {
            max = threads[i].length;
        }
    }

    /* execute them */
    while(lines < max) {
        for(var i=0; i<threads.length; i++) {
            for(var j = lines; j < threads[i].length && j < (lines + quantum); j++) {
                eval(threads[i][j]);
            }
        }
        lines += quantum;
    }
}

Answer 16

vous pouvez utiliser jetworker, wrapper sur webworkerhttps://github.com/uxitten/jetworker

Answer 17

Le multithreading avec javascript est clairement possible en utilisant les webworkers apportés par HTML5.

La principale différence entre les webworkers et un environnement multithread standard est que les ressources mémoire ne sont pas partagées avec le thread principal, une référence à un objet n'est pas visible d'un thread à l'autre.Les threads communiquent en échangeant des messages, il est donc possible d'implémenter un algorithme de synchronisation et d'appel de méthodes simultanées suivant un modèle de conception événementiel.

De nombreux frameworks existent permettant de structurer la programmation entre threads, parmi lesquels OODK-JS, un framework POO js supportant la programmation concurrentehttps://github.com/GOMServices/oodk-js-oop-for-js