Waarom ondersteunt JavaScript geen multithreading?

Is het een bewuste ontwerpbeslissing of een probleem met onze huidige browsers dat in de komende versies zal worden verholpen?

Antwoord 1, autoriteit 100%

JavaScript ondersteunt geen multi-threading omdat de JavaScript-interpreter in de browser een enkele thread (AFAIK) is. Zelfs Google Chrome laat het JavaScript van een enkele webpagina niet gelijktijdig draaien, omdat dit enorme gelijktijdigheidsproblemen zou veroorzaken in bestaande webpagina’s. Het enige dat Chrome doet, is meerdere componenten (verschillende tabbladen, plug-ins, enzovoort) scheiden in afzonderlijke processen, maar ik kan me niet voorstellen dat een enkele pagina meer dan één JavaScript-thread heeft.

U kunt echter, zoals werd gesuggereerd, setTimeoutgebruiken om een soort planning en “nep” gelijktijdigheid toe te staan. Dit zorgt ervoor dat de browser de controle over de renderingthread terugkrijgt en de JavaScript-code start die wordt geleverd aan setTimeoutna het opgegeven aantal milliseconden. Dit is erg handig als u de viewport (wat u ziet) wilt laten vernieuwen terwijl u er bewerkingen op uitvoert. Gewoon doorlussen bijv. coördinaten en het dienovereenkomstig bijwerken van een element laat je alleen de begin- en eindposities zien, en niets daartussenin.

We gebruiken een abstractiebibliotheek in JavaScript waarmee we processen en threads kunnen maken die allemaal worden beheerd door dezelfde JavaScript-interpreter. Hierdoor kunnen we acties op de volgende manier uitvoeren:

• Proces A, draad 1
• Proces A, draad 2
• Proces B, draad 1
• Proces A, draad 3
• Proces A, draad 4
• Proces B, draad 2
• Proces A onderbreken
• Proces B, draad 3
• Proces B, draad 4
• Proces B, draad 5
• Proces A starten
• Proces A, draad 5

Dit maakt enige vorm van planning mogelijk en vervalst parallellisme, starten en stoppen van threads, enzovoort, maar het zal geen echte multi-threading zijn. Ik denk niet dat het ooit in de taal zelf zal worden geïmplementeerd, aangezien echte multi-threading alleen nuttig is als de browser een enkele pagina multi-threaded (of zelfs meer dan één core) kan uitvoeren, en de problemen daar zijn veel groter dan de extra mogelijkheden.

Bekijk dit voor de toekomst van JavaScript:
https://developer.mozilla. org/presentations/xtech2006/javascript/

Antwoord 2, autoriteit 14%

JavaScript multi-threading (met enkele beperkingen) is hier. Google heeft werkers voor Gears geïmplementeerd en werkers worden opgenomen in HTML5. De meeste browsers hebben al ondersteuning voor deze functie toegevoegd.

De draadveiligheid van gegevens is gegarandeerd omdat alle gegevens die naar/van de werknemer worden gecommuniceerd, geserialiseerd/gekopieerd zijn.

Lees voor meer informatie:

http://www.whatwg.org/specs/web-workers /huidig-werk/

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

Antwoord 3, autoriteit 12%

Traditioneel was JS bedoeld voor korte, snel lopende stukjes code. Als je grote berekeningen had, deed je dat op een server – het idee van een JS+HTML appdie lange tijd in je browser draaide en niet-triviale dingen deed, was absurd.

Natuurlijk hebben we dat nu. Maar het zal even duren voordat browsers de achterstand hebben ingehaald – de meeste zijn ontworpen rond een model met één thread, en het is niet eenvoudig om dat te veranderen. Google Gears omzeilt veel potentiële problemen door te eisen dat de uitvoering op de achtergrond geïsoleerd is – geen wijziging van de DOM (aangezien dat niet thread-safe is), geen toegang tot objecten die door de hoofdthread zijn gemaakt (idem). Hoewel dit beperkend is, zal dit waarschijnlijk het meest praktische ontwerp voor de nabije toekomst zijn, zowel omdat het het ontwerp van de browser vereenvoudigt, en omdat het het risico vermindert dat onervaren JS-codeerders met threads laten rommelen…

@marcio:

Waarom is dat een reden om geen multi-threading in Javascript te implementeren? Programmeurs kunnen doen wat ze willen met de tools die ze hebben.

Laten we ze dan geen tools geven die zo gemakkelijk te misbruikenzijn dat elke andere website die ik open mijn browser laat crashen. Een naïeve implementatie hiervan zou je rechtstreeks naar het gebied brengen dat MS zoveel hoofdpijn heeft bezorgd tijdens de ontwikkeling van IE7: add-on-auteurs speelden snel en losjes met het threading-model, wat resulteerde in verborgen bugs die duidelijk werden toen de levenscycli van objecten op de primaire thread veranderden . SLECHT. Als je multi-threaded ActiveX-add-ons voor IE schrijft, denk ik dat het bij het gebied hoort; betekent niet dat het verder hoeft te gaan.

Antwoord 4, autoriteit 6%

Ik weet niet wat de reden voor deze beslissing is, maar ik weet dat je een aantal voordelen van multi-threaded programmeren kunt simuleren met setTimeout. Je kunt de illusie wekken dat meerdere processen tegelijkertijd dingen doen, maar in werkelijkheid gebeurt alles in één thread.

Laat je functie een beetje werk doen en roep dan zoiets aan als:

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

En alle andere dingen die gedaan moeten worden (zoals UI-updates, geanimeerde afbeeldingen, enz.) zullen gebeuren wanneer ze de kans krijgen.

Antwoord 5, autoriteit 5%

Bedoelt u waarom de taal geen multithreading ondersteunt of waarom geen JavaScript-engines in browsers multithreading ondersteunen?

Het antwoord op de eerste vraag is dat JavaScript in de browser bedoeld is om te worden uitgevoerd in een sandbox en op een machine/OS-onafhankelijke manier, om multithreading-ondersteuning toe te voegen zou de taal ingewikkelder maken en de taal te nauw met het besturingssysteem verbinden .

Antwoord 6, autoriteit 4%

Node.js 10.5+ ondersteunt workerthreadsals experimentele functie (u kunt deze gebruiken met de vlag –experimental-workeringeschakeld): https://nodejs.org/api/worker_threads.html

Dus de regel is:

• als je I/O-gebonden opsmoet doen, gebruik dan het interne mechanisme (ook bekend als callback/promise/async-await)
• als je CPU-gebonden opsmoet doen, gebruik dan worker-threads.

Worker-threads zijn bedoeld als threads met een lange levensduur, wat betekent dat je een achtergrondthread spawnt en er vervolgens mee communiceert via het doorgeven van berichten.

Anders, als u een zware CPU-belasting moet uitvoeren met een anonieme functie, kunt u kiezen voor https://github.com/wilk/microjob, een kleine bibliotheek gebouwd rond werkthreads.

Antwoord 7, autoriteit 3%

Net zoals Matt B zei, de vraag is niet erg duidelijk. Ervan uitgaande dat u vraagt ​​naar multithreading-ondersteuning in de taal: omdat het niet nodig is voor 99,999% van de toepassingen die momenteel in de browser worden uitgevoerd. Als je het echt nodig hebt, zijn er een tijdelijke oplossingen (zoals het gebruik van venster.settimeout).

In het algemeen is multithreading erg, heel, heel, heel, heel hard (heb ik gezegd dat het moeilijk is?) Om goed te krijgen, tenzij je extra beperkingen hebt ingevoerd (zoals alleen onveranderlijke gegevens gebruiken).

Antwoord 8

Intel heeft een aantal open-source-onderzoek gedaan naar multithreading in JavaScript, het werd onlangs getoond op GDC 2012.
Hier is de link voor de video . De onderzoeksgroep gebruikte OpenCl die zich voornamelijk richt op Intel Chip Sets en Windows OS. Het project is code-genaamd RiverTrail en de code is beschikbaar op GitHub

Nog een nuttige links:

Bouw van een computerwegen voor webtoepassingen

Antwoord 9

Momenteel ondersteunen enkele browsers multithreading. Dus, als u dat nodig hebt, kunt u specifieke bibliotheken gebruiken. Bekijk bijvoorbeeld de volgende materialen:

• https://developer.mozilla.org / EN-US / DOCS / WEB / API / WEB_WORKERS_API / GEBRUIK_WEB_WORKERS
  (Ondersteuning achtergronddraden);

• https://keithWhor.github.io/multithread.js/ (de bibliotheek).

Antwoord 10

Javascript is een taal met één thread. Dit betekent dat het één call-stack en één geheugenheap heeft. Zoals verwacht, voert het code in volgorde uit en moet het het uitvoeren van een stukcode voltooien voordat het naar de volgende gaat. Het is synchroon, maar soms kan dat schadelijk zijn. Als een functie bijvoorbeeld een tijdje nodig heeft om uit te voeren of ergens op moet wachten, bevriest het in de tussentijd alles.

Antwoord 11

Het zijn de implementaties die geen multithreading ondersteunen. Momenteel biedt Google Gears een manier om een of andere vorm van gelijktijdigheid te gebruiken door externe processen uit te voeren, maar dat is het dan ook.

De nieuwe browser die Google vandaag zou uitbrengen (Google Chrome) voert een bepaalde code parallel uit door deze tijdens het proces te scheiden.

De kerntaal kan natuurlijk dezelfde ondersteuning hebben als bijvoorbeeld Java, maar ondersteuning voor zoiets als Erlang’s concurrency is nog lang niet in de buurt.

Antwoord 12

Voor zover ik heb gehoord heeft Google Chrome javascript met meerdere threads, dus het is een probleem met de huidige implementaties.

Antwoord 13

Zonder de juiste taalondersteuning voor threadsynchronisatie, is het zelfs niet logisch om nieuwe implementaties te proberen. Bestaande complexe JS-apps (bijvoorbeeld alles dat ExtJS gebruikt) zouden hoogstwaarschijnlijk onverwacht crashen, maar zonder een synchronizedtrefwoord of iets dergelijks zou het ook erg moeilijk of zelfs onmogelijk zijn om nieuwe programma’s te schrijven die zich correct gedragen.

Antwoord 14

U kunt echter de eval-functie gebruiken om de gelijktijdigheid IN ENIGE MATE te brengen

/* 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;
    }
}

Antwoord 15

Multi-threading met javascript is duidelijk mogelijk met behulp van webworkers die door HTML5 worden gebracht.

Het belangrijkste verschil tussen webworkers en een standaard multithreading-omgeving is dat geheugenbronnen niet worden gedeeld met de hoofdthread, een verwijzing naar een object is niet zichtbaar van de ene thread naar de andere. Threads communiceren door berichten uit te wisselen, daarom is het mogelijk om een synchronisatie- en gelijktijdige methodeaanroepalgoritme te implementeren volgens een gebeurtenisgestuurd ontwerppatroon.

Er bestaan veel frameworks waarmee programmatie tussen threads kan worden gestructureerd, waaronder OODK-JS, een OOP js-framework dat gelijktijdig programmeren ondersteunt
https://github.com/GOMServices/oodk-js-oop-for-js