позволяет говорить о коде JavaScript, который имеет методы setInterval каждые 2 сек.
У меня также есть событие анимации onblur для некоторого элемента управления.
В случае, когда onblur встречается (+ анимация), я могу получить функцию setInterval.
Итак, мой вопрос:
Асинхронное программирование означает многопоточность? (каким-либо образом?)
Я знаю, что Javascript не является многопоточным языком.
Итак...?
Нет. Это означает буквально, что это значит - асинхронно. Понимание различия между асинхронным программированием и потоковым программированием имеет решающее значение для вашего успеха в качестве программиста.
В традиционной, не-потоковой среде, когда функция должна ждать внешнего события (например, сетевого события, события клавиатуры или мыши или даже события синхронизации), программа должна ждать, пока это событие не произойдет.
В многопоточной среде многие отдельные потоки программирования работают одновременно. (В зависимости от количества процессоров и поддержки операционной системы это может быть буквально истинным, или это может быть иллюзия, созданная сложными алгоритмами планирования). По этой причине многопоточные среды сложны и связаны с проблемами потоков, блокирующих друг друга в памяти, чтобы предотвратить их перегрузку друг друга.
В асинхронной среде один поток процесса работает все время, но он может по причинам, связанным с событиями (и это ключ), переключиться с одной функции на другую. Когда происходит событие, и когда текущий запущенный процесс попадает в точку, в которой он должен ждать другого события, ядро javascript затем сканирует его список событий и доставляет следующий, в (формально) неопределенном (но, вероятно, детерминированном) порядке, менеджеру событий.
По этой причине асинхронное программирование, управляемое событиями, позволяет избежать многих ошибок традиционного многопоточного программирования, таких как проблемы с памятью. Там могут быть условия гонки, так как порядок обработки событий не зависит от вас, но они редки и проще в управлении. С другой стороны, поскольку обработчик событий не доставляет события до тех пор, пока текущая работа не попадет в незанятое место, некоторые функции могут выдержать голод остальной части программирования. Это происходит в Node.js, например, когда люди глупо делают много тяжелой математики на сервере - лучше всего запихивают на маленький сервер, который node затем "ждет", чтобы доставить ответ. Node.js - очень маленький коммутатор для событий, но все, что занимает больше 100 миллисекунд, должно обрабатываться на стороне клиента/сервера.
В среде браузера события DOM рассматриваются как автоматические точки события (они должны быть, изменение DOM обеспечивает множество событий), но даже там плохо написанный Javascript может голодать ядро, поэтому и Firefox, и У Chrome есть эти "Это script перестало отвечать" обработчикам прерываний.
Однопоточный цикл событий является хорошим примером асинхронности в одном потоковом языке.
Концепция заключается в том, что вы прикрепляете обработчики обратного вызова doLater к eventLoop. Затем eventLoop представляет собой всего лишь while(true), который проверяет, соответствует ли конкретная метка времени для каждого обработчика doLater, и если это так вызывает обработчик.
Для заинтересованных, вот наивная (и ужасно неэффективная игрушка) реализация однопоточного цикла событий в JavaScript
Это означает, что без какого-либо вида диспетчера потоков нитей ОС вашего отдельного потока ваш вынужденный ожидание будет ждать обратных вызовов doLater.
Если у вас есть вызов sleep, вы можете просто сделать sleep до следующего обработчика doLater, который более эффективен, тогда ожидание будет ждать, так как вы отложите свой единственный поток и позвольте ОС делать другие вещи.
Только в том смысле, что он безошибочно выполняет код и рискует условиями гонки. Вы не получите каких-либо преимуществ от использования тайм-аутов и интервалов.
Тем не менее, HTML5 WebWorkers действительно поддерживает реальную многопоточность в браузере: http://www.html5rocks.com/en/tutorials/workers/basics/
Имеет ли смысл использовать асинхронные шаблоны проектирования, если нечего запускать параллельно?
Если есть обратный вызов, что-то должно его вызвать. Единицы исполнения - это потоки, поэтому да, какой-то другой поток должен вызвать обратный вызов, либо напрямую, либо путем очередности очередного асинхронного вызова процедуры в инициирующий поток.