Это JavaScript гарантированно однопоточный?

Я бы сказал Да-потому что практически весь существующий (по крайней мере, все нетривиальные) код javascript сломается, если движок javascript браузера будет работать асинхронно.

добавьте к этому тот факт, что HTML5 уже указывает веб-работников (явный, стандартизированный API для многопоточного кода javascript) введение многопоточности в базовый Javascript было бы в основном бессмысленным.

(Примечание для других комментаторов: хотя setTimeout/setInterval, HTTP-request onload events (XHR)и события пользовательского интерфейса (click, focus и т. д.) обеспечивают грубое впечатление многопоточности - они все еще выполняются по одной временной шкале-по одному за раз , поэтому, даже если мы не знаем их порядок выполнения заранее, нет необходимости беспокоиться о внешних условиях, изменяющихся во время выполнения обработчика событий, временной функции или обратного вызова XHR.)

да, хотя вы все еще можете испытывать некоторые проблемы параллельного программирования (в основном условия гонки) при использовании любого из асинхронных API, таких как setInterval и xmlhttp обратные вызовы.

да, хотя Internet Explorer 9 будет компилировать ваш Javascript в отдельном потоке при подготовке к выполнению в основном потоке. Однако это ничего не меняет для вас как программиста.

JavaScript / ECMAScript предназначен для жизни в среде хоста. То есть JavaScript на самом деле не ничего если среда хоста не решит проанализировать и выполнить данный скрипт и предоставить объекты среды, которые позволяют JavaScript действительно быть полезными (например, DOM в браузерах).

Я думаю, что данная функция или блок скрипта будут выполняться по строкам, и это гарантировано для JavaScript. Однако, возможно, среда хоста может выполнить несколько сценариев одновременно. Или среда хоста всегда может предоставить объект, обеспечивающий многопоточность. setTimeout и setInterval являются примерами или, по крайней мере, псевдо-примерами среды хоста, предоставляющей способ выполнения некоторого параллелизма (даже если это не совсем параллелизм).

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

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

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

Nodejs следовал подходу браузеров.

носорог двигатель поддерживает запуск кода js в разных потоках. Казни не могут совместно использовать контекст, но они могут совместно использовать область. Для этого конкретного случая в документации указано:

..."Rhino гарантирует, что доступ к свойствам объектов JavaScript является атомарным по потокам, но не дает никаких гарантий для сценариев, выполняющихся в одной области одновременно.Если два скрипта используют одну и ту же область одновременно, скрипты отвечают за координацию любых обращений к общие переменные."

из чтения документации Rhino я заключаю, что кто-то может написать api javascript, который также порождает новые потоки javascript, но api будет специфичным для rhino (например, узел может порождать только новый процесс).

Я полагаю, что даже для движка, поддерживающего несколько потоков в javascript, должна быть совместимость со сценариями, которые не рассматривают многопоточность или блокировка.

по поводу браузеров и nodejs как я вижу это:

• выполняется ли весь код js в одном потоке? : Утвердительный ответ.

• может ли код js вызвать запуск других потоков? : Утвердительный ответ.

• могут ли эти потоки мутировать контекст выполнения js?: Нет. Но они могут (прямо/косвенно(?)) добавить в очередь событий.

Итак, в случае браузеров и nodejs (и, вероятно, много других движки) javascript не многопоточен, но сами движки.

нет.

Я иду против толпы, но медведь со мной. Один сценарий JS предназначен для эффективно однопоточный, но это не означает, что его нельзя интерпретировать по-разному.

предположим, у вас есть следующий код...

var list = [];
for (var i = 0; i < 10000; i++) {
  list[i] = i * i;
}

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

первый поток

for (var i = 0; i < 5000; i++) {
  list[i] = i * i;
}

второй поток

for (var i = 5000; i < 10000; i++) {
  list[i] = i * i;
}

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

пока я не знаю об обнаружении VM распараллеливаемый код, подобный этому, кажется вероятным, что он может появиться в будущем для JIT VMs, поскольку в некоторых ситуациях он может предложить большую скорость.

принимая эту концепцию дальше, возможно, что код может быть аннотирован, чтобы VM знал, что конвертировать в многопоточный код.

// like "use strict" this enables certain features on compatible VMs.
"use parallel";

var list = [];

// This string, which has no effect on incompatible VMs, enables threading on
// this loop.
"parallel for";
for (var i = 0; i < 10000; i++) {
  list[i] = i * i;
}

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

@Bobince предоставляет действительно непрозрачный ответ.

Риффинг ответа Мара Эрлигссона, Javascript всегда однопоточный из-за этого простого факта: все в Javascript выполняется по одной временной шкале.

это строгое определение однопоточного языка программирования.

Ну, Chrome является многопроцессорным, и я думаю, что каждый процесс имеет дело со своим собственным кодом Javascript, но, насколько знает код, он "однопоточный".

в Javascript нет никакой поддержки многопоточности, по крайней мере, явно, поэтому это не имеет значения.

Я пробовал пример @bobince с небольшими изменениями:

<html>
<head>
    <title>Test</title>
</head>
<body>
    <textarea id="log" rows="20" cols="40"></textarea>
    <br />
    <button id="act">Run</button>
    <script type="text/javascript">
        let l= document.getElementById('log');
        let b = document.getElementById('act');
        let s = 0;

        b.addEventListener('click', function() {
            l.value += 'click begin\n';

            s = 10;
            let s2 = s;

            alert('alert!');

            s = s + s2;

            l.value += 'click end\n';
            l.value += `result = ${s}, should be ${s2 + s2}\n`;
            l.value += '----------\n';
        });

        window.addEventListener('resize', function() {
            if (s === 10) {
                s = 5;
            }

            l.value+= 'resize\n';
        });
    </script>
</body>
</html>

Итак, когда вы нажимаете Run, close Alert popup и делаете "один поток", вы должны увидеть что-то вроде этого:

click begin
click end
result = 20, should be 20

но если вы попытаетесь запустить это в Opera или Firefox stable на Windows и минимизировать / максимизировать окно с всплывающим предупреждением на экране, то будет что-то вроде этого:

click begin
resize
click end
result = 15, should be 20

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

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