JavaScript гарантированно будет однопоточным?

Хороший вопрос. Я бы хотел сказать «да». Я не могу.

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

(*: игнорирование вопроса о том, действительно ли браузеры реализуют свои JS-движки с использованием одного потока ОС, или же WebWorkers вводят другие ограниченные потоки выполнения.)

Однако на самом деле это не 'Не совсем правда , подлыми противными способами.

Самый частый случай - немедленные события. Браузеры сразу активируют их, когда ваш код что-то вызывает:

 var l = document.getElementById ('log'); var i = document.getElementById ('inp'); i.onblur = function () {l.value + = 'размытие \ п'; }; setTimeout (function () {l.value + = 'войти в систему \ n'; l.focus (); l.value + = 'выйти из системы \ n';}, 100); i.focus (); 

Результатов в входа в систему, размытие, выйдите из системы на всех устройствах, кроме IE. Эти события запускаются не только потому, что вы вызвали focus () напрямую, они могут произойти из-за того, что вы вызвали alert () , или открыли всплывающее окно, или что-то еще, что движется фокус.

Это также может привести к другим событиям. Например, добавьте i.onchange listener и введите что-нибудь во входных данных до того, как вызов focus () расфокусирует его, и порядок журнала будет войти, изменить, размыть, выйти , кроме Opera где это вход в систему, размытие, выход из системы, изменение и IE, где (еще менее объяснимо) вход в систему, изменение, выход из системы, размытие .

Аналогичным образом вызов click () для элемента, который его предоставляет, вызывает обработчик onclick сразу во всех браузерах (по крайней мере, это согласованно!).

(Здесь я использую свойства прямого обработчика событий on ... , но то же самое происходит с addEventListener и attachEvent .)

Также существует множество обстоятельств, при которых события могут срабатывать, пока ваш код встроен, несмотря на то, что вы не сделали ничего , чтобы спровоцировать его. Пример:

 var l = document.getElementById ('log'); document.getElementById ('act'). onclick = function () {l.value + = 'предупреждение в \ n'; предупреждение ('предупреждение!'); l.value + = 'предупреждение \ п'; }; window.onresize = function () {l.value + = 'изменение размера \ n'; }; 

    alert  

Hit alert , и вы получите модальное диалоговое окно. Никакой больше скрипт не будет выполняться, пока вы не закроете этот диалог, да? Неа. Измените размер главного окна, и вы получите предупреждение , изменение размера, предупреждение в текстовой области.

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

Вы можете подумать, что только resize (и, вероятно, еще несколько, например scroll ) могут срабатывать, когда пользователь не взаимодействует с браузером, потому что скрипт имеет резьбу. И для отдельных окон вы можете быть правы. Но все это пойдет на пользу, как только вы начнете писать межоконные скрипты. Для всех браузеров, кроме Safari, который блокирует все окна / вкладки / фреймы, когда любой из них занят, вы можете взаимодействовать с документом из кода другого документа, работая в отдельном потоке выполнения и вызывая любые связанные обработчики событий для Огонь.

Места, в которых события, которые вы можете вызвать, могут возникать, пока скрипт все еще связан:

• , когда модальные всплывающие окна ( предупреждение , подтверждают , приглашение ) открыты во всех браузерах, кроме Opera;

• во время showModalDialog в браузерах, которые его поддерживают;

• диалоговое окно «Сценарий на этой странице может быть занят ...», даже если вы решите позволить скрипту продолжить выполнение, позволяет запускать и обрабатывать такие события, как изменение размера и размытие, даже когда скрипт находится в середине цикла занятости, за исключением Opera.

• Некоторое время назад для меня в IE с подключаемым модулем Sun Java вызов любого метода в апплете мог разрешить запуск событий и повторный ввод сценария. Это всегда была ошибка, зависящая от времени, и, возможно, Sun исправила ее с тех пор (я, конечно, на это надеюсь).

• , наверное, больше. Прошло много времени с тех пор, как я это тестировал, и с тех пор браузеры стали усложняться.

Таким образом, большинству пользователей в большинстве случаев кажется, что JavaScript имеет строгий, управляемый событиями единственный поток выполнения. На самом деле такого нет. Неясно, насколько это просто ошибка, а насколько преднамеренный дизайн, но если вы пишете сложные приложения, особенно кросс-оконные / фреймовые -сценариев, есть все шансы, что они могут вас укусить - причем прерывистыми, трудно поддающимися отладке способами.

В худшем случае вы можете решить проблемы параллелизма, переадресовав все ответы на события. Когда приходит событие, поместите его в очередь и обработайте очередь позже, используя функцию setInterval . Если вы пишете фреймворк, который собираетесь использовать в сложных приложениях, это может быть хорошим ходом. Мы надеемся, что postMessage также облегчит боль кросс-документального скриптинга в будущем.