Почему JavaScript не поддерживает многопоточность?

Традиционно JS предназначался для коротких, быстрых фрагментов кода. Если у вас были основные вычисления, вы сделали это на сервере - идея JS + HTML-приложения, которая длилась в вашем браузере длительное время, делала нетривиальные вещи, была абсурдной.

Конечно, теперь у нас это есть. Но для браузеров потребуется немного, чтобы догнать - большинство из них были спроектированы вокруг однопоточной модели, и изменить это непросто. Google Gears ставит перед собой множество потенциальных проблем, требуя, чтобы фоновое выполнение было изолировано - без изменения DOM (так как это не потокобезопасно), без доступа к объектам, созданным основным потоком (то же самое). Хотя это и ограничивает, это, скорее всего, будет самым практичным дизайном в ближайшем будущем, поскольку это упрощает дизайн браузера и потому, что это снижает риск, связанный с тем, что неопытные JS-кодеры запутались с потоками...

@marcio:

Почему это причина не для реализации многопоточности в Javascript? Программисты могут делать все, что захотят, с помощью инструментов, которые у них есть.

Итак, давайте не дадим им инструменты, которые настолько легки для злоупотребления, что каждый другой открываемый веб-сайт заканчивает сбой моего браузера. Наивная реализация этого приведет вас прямо к территории, которая вызвала много головных болей MS во время разработки IE7: надёжные авторы играли быстро и свободно с помощью модели потоковой передачи, что приводило к скрытым ошибкам, которые стали очевидными, когда жизненные циклы объектов были изменены в основной цепочке, ПЛОХО. Если вы пишете многопоточные дополнения ActiveX для IE, я предполагаю, что он поставляется с территорией; не означает, что он должен идти дальше этого.

Многопоточность JavaScript (с некоторыми ограничениями) находится здесь. Google внедряет рабочих для Gears, а рабочие включены в HTML5. Большинство браузеров уже добавили поддержку этой функции.

Безопасность потоков данных гарантируется, поскольку все данные, передаваемые/от рабочего, сериализуются/копируются.

Для получения дополнительной информации прочитайте:

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

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

Я не знаю обоснования для этого решения, но я знаю, что вы можете имитировать некоторые преимущества многопоточного программирования, используя setTimeout. Вы можете дать иллюзию нескольких процессов, которые делают вещи одновременно, хотя на самом деле все происходит в одном потоке.

Просто выполните свою работу немного, а затем вызовите что-то вроде:

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

И все, что нужно делать (например, обновления пользовательского интерфейса, анимированные изображения и т.д.), произойдет, когда они получат шанс.

Multithread.js обертывает Web Workers и позволяет легко многопоточно обрабатывать JS. Работает во всех новых браузерах, включая iOS Safari.:)

Вы имеете в виду, почему язык не поддерживает многопоточность или почему механизмы JavaScript в браузерах не поддерживают многопоточность?

Ответ на первый вопрос заключается в том, что JavaScript в браузере предназначен для работы в песочнице и в автономном режиме с машиной/ОС, добавление поддержки многопоточности затруднит язык и слишком близко привяжет язык к ОС.

Как и матовый b, вопрос не очень ясен. Предполагая, что вы задаете вопрос о поддержке многопоточности в языке: потому что он не нужен для 99.999% приложений, работающих в браузере в настоящее время. Если вам это действительно нужно, есть обходные пути (например, использование window.setTimeout).

В целом многопоточность очень, очень, очень, очень, очень и очень тяжелая (я сказал, что это сложно?), чтобы получить право, если вы не введете дополнительные ограничения (например, используя только неизменяемые данные).

Корпорация Intel провела несколько исследований с открытым исходным кодом по многопоточности в Javascript, которая была недавно продемонстрирована на GDC 2012. Вот ссылка на видео. Исследовательская группа использовала OpenCL, которая в основном фокусируется на наборах чипов Intel и ОС Windows. Проект под кодовым названием RiverTrail, и код доступен на GitHub

Еще несколько полезных ссылок:

Построение вычислительной магистрали для веб-приложений

В настоящее время некоторые браузеры поддерживают многопоточность. Итак, если вам нужно, вы можете использовать определенные библиотеки. Например, просмотрите следующие материалы:

• https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers (поддержка фоновых потоков);

• https://keithwhor.github.io/multithread.js/ (библиотека).

Node.js 10. 5+ поддерживает рабочие потоки в качестве экспериментальной функции (вы можете использовать ее с включенным флагом --experimental-worker): https://nodejs.org/api/worker_threads.html

Итак, правило таково:

• если вам нужно выполнить операции ввода-вывода с привязкой, то используйте внутренний механизм (он же callback/обещание /async-await)
• если вам нужно выполнить операции с привязкой к процессору, используйте рабочие потоки.

Рабочие потоки предназначены для долгоживущих потоков, то есть вы создаете фоновый поток, а затем общаетесь с ним посредством передачи сообщений.

В противном случае, если вам нужно выполнить большую загрузку ЦП с помощью анонимной функции, вы можете воспользоваться https://github.com/wilk/microjob, крошечной библиотекой, построенной на рабочих потоках.

вы можете использовать jetworker, обертку на веб-сайте https://github.com/uxitten/jetworker

Однако вы можете использовать функцию eval, чтобы принести concurrency В НЕКОТОРЫЕ EXTENT

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

Без надлежащей поддержки языка для синхронизации потоков, это даже не имеет смысла для новых реализаций. Существующие сложные JS-приложения (например, что-либо, использующие ExtJS), скорее всего, неожиданно произойдут, но без ключевого слова synchronized или чего-то подобного, также будет очень сложно или даже невозможно записать новые программы, которые ведут себя правильно.

В соответствии с в этой статье уже возможно реализовать потоки JavaScript.

Насколько я слышал, Google Chrome будет иметь многопоточный javascript, поэтому это проблема "текущей реализации".

Это реализации, которые не поддерживают многопоточность. В настоящее время Google Gears предоставляет способ использовать некоторую форму concurrency, выполняя внешние процессы, но об этом.

Новый браузер Google, который должен выпустить сегодня (Google Chrome), выполняет параллельный параллельный код, отделяя его в процессе.

Основной язык, конечно, может иметь такую ​​же поддержку, как, например, Java, но поддержка чего-то вроде Erlang concurrency нигде не приближается к горизонту.

Многопоточность с javascript, очевидно, возможна с помощью веб-мастеров, приносящих HTML5.

Основное различие между веб-мастерами и стандартной многопотоковой средой - это ресурсы памяти, которые не разделяются с основным потоком, ссылка на объект не видна из одного потока в другой. Потоки обмениваются сообщениями, поэтому можно реализовать алгоритм вызова синхронизации и параллельного метода после шаблона проектирования, управляемого событиями.

Существует множество инфраструктур, позволяющих структурировать программирование между потоками, в том числе OODK-JS, фреймворк OOP js, поддерживающий параллельное программирование https://github.com/GOMServices/oodk-js-oop-for-js