Действительно ли асинхронный, неблокирующий JavaScript невозможен?

Question

Итак, я что-то здесь упускаю?

Все движки JavaScript в популярных современных браузерах (по состоянию на 2011 год) однопоточные .

Это означает, что хотя СОБЫТИЯ могут происходить асинхронно, они все еще находятся в очереди (в «одном файле») для выполнения.

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

Итак, другие «советы», которые я видел в Интернете, разбивают и выполняют инициализацию блоков кода с помощью setTimeout, что будет фиктивным, неправильным советом - таймер также является очередью из одного файла и выполняется только по порядку. С помощью setTimeout вы просто вызываете неупорядоченное выполнение через таймер и позволяете другим событиям в браузере (например, щелчки мыши или нажатия клавиш и т. Д.) Переходить в очередь - что само по себе может быть полезно, но это, конечно, не асинхронное выполнение кода.

Если я прав, есть куча плохих, неправильно понятых советов, которые слишком часто повторяются.

Answer 1

Не смешиваете ли вы асинхронность с параллелизмом? Это правда, что в среде JS браузера не существует параллелизма (кроме веб-работников и всего, что делает браузер внутри, например ввода-вывода и рендеринга), но асинхронность просто означает что все вызовы не блокируются, и поток управления всегда возвращается немедленно.

Ваши определения «блокирования» / «неблокирования» также неясны. Широко распространенный смысл вызова функции блокировки заключается в том, что он не возвращает управление вызывающей стороне до тех пор, пока не завершатся все вычисления, ввод-вывод и т. Д. Это ничего не говорит о параллелизме.

Answer 2

AFAIK, Javascript является асинхронным в том смысле, что, хотя он работает в одном потоке, указанный поток работает одновременно с другими потоками, выполняющими другие действия (например, рендеринг страницы) независимо от механизма Javascript.

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

Answer 3

Вы правы относительно того, как движки JavaScript работают на отдельных страницах, w / r / t setTimeout и тому подобное.(Вообще говоря, это хорошая вещь, потому что это значительно облегчает написание JavaScript и рассуждения о коде.) Если вы еще не читали его, Джон Резиг из jQuery написал убедительное объяснение таймеров JavaScript .

Действительно асинхронный JavaScript в браузере определяется API Web Workers.

• Web Workers (Википедия)
• Использование веб-работников (MDC)
• Джон Резиг по веб-работникам

Answer 4

Да, но это не исключает асинхронность.Асинхронная обработка и потоковая обработка совершенно разные.Фактически, щелчки мыши и нажатия клавиш обычно являются единственной вещью, которую ppl пытается выполнить с помощью setTimeout.Пусть Gui успеет пообщаться во время перебора чисел.

Answer 5

Я не гуру javascript, так что это только мои размышления, но мне кажется, что вы, возможно, частично правы.

Однако, если вы думаете о потоке Javascript как о «времени» и позволяете другим функциям прыгать в потоке времени везде, где вам это нужно, то это делает javascript по существу действующим как неблокирующий процесс.

С другой стороны, HTML 5 определяет веб-работников, которые (если я правильно понимаю) являются «многопоточными» в том смысле, что многие могут обрабатывать одновременно.

Answer 6

Веб-работники как раз для этого.Хотя из-за плохой доступности браузера они пока не могут быть решением.

Answer 7

Если оставить в стороне новое средство HTML5 «веб-работник», вы правы.