Comments 38
Всегда думал что асинхронный вызов создает что-то типа потока внутри общего контейнера (который снаружи выглядит как один процесс). Как в единую очередь вызовов попадают асинхронные вызовы? Просто подмешиваются по мере исполнения? А если окружение реализует всю асинхронную кухню, то почему это не вид многопоточности?
Я понимаю различия многопоточности и асинхронности. Но если я через асинхронные вызовы могу создавать и удалять некие условные "потоки", значит эта "условная многопоточность" все-таки не совсем неуправляемая? Конечно это не горутины, но… Так в итоге, как именно обрабатываются "окружением" асинхронные вызовы? Конкурентно? Зависит от движка?
Мне навскидку приходит несколько вариантов реализации управления потоками (отдельными контекстами исполнения, созданными через асинхронные вызовы). По управлением я понимаю, как минимум, создание/удаление, блокировку, обмен данными. Помимо этого, существуют уже реализованные библиотеки и тулзы для "чего-то типа" мультитридинга в JS. Кроме того, не вижу причин не принимать во внимание веб-воркеры. Во многом ответ на вопрос о многопоточности в JS лежит именно в тонкостях реализации того, что вы назвали окружением. Но вы старательно избегаете этой темы, хотя изначально взялись объяснить ("зависит от реализации" — это, извините, не ответ). Надеюсь на следующую статью.
имхо устоявшийся термин js асинхронность — это и есть многопоточность. Многопоточность, разделяющая процессорное время (в данном случае — очередь вызовов).
Кто помнит *nix-подобные системы и Windows 9x как раз и стали теми ОС (надеюсь никого не забыл?), кто привнесли многозадачность на единственном процессоре за счёт разделения процессорного времени. И именно в такой ситуации и зародилась «классическая» многопоточность.
Единственной отличие js — не вижу никакого способа внешнего управления потоками (проритет, возможность остановки, ...)
За отличные иллюстрации отдельный +
ШТА?
Дорогой автор, вся «асинхронность», т.е. порядок выполнения job-ов, описаны непосредственно в стандарте ECMAScript
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-executable-code-and-execution-contexts
Почитайте на досуге. Например, промисы принципиально по стандарту работают асинхронно.
WebAPI — это просто все API, определённые в браузере, а не в стандарте ECMA.
Ну какая же это асинхронность, это всего лишь отложенный вызов функции, который достигается перекладыванием на верх ивэнт лупа. Так же как и nextTick. Есть ещё setImmediate, который кладёт вызов функции вниз ивэнт лупа. Поэтому манипуляции с ивэнт лупом можно назвать "отложенностью", но никак не "асинхронностью".
Во-вторых, а дайте определение «асинхронности» и «отложенности», пожалуйста.
Мой комментарий был лишь к тому, что бы читатель понимал из-за чего достигается подобное поведение. И я например не считаю, что это можно назвать асинхронностью, но и в дискуссию также не хочу вступать, если считаете иначе, то пускай так и будет. Это всего лишь мое мнение. Но изменение очереди вызова функций, лично мне, сложно назвать асинхронностью. Ведь в конце концов, вызов функций остаётся синхронным, лишь порядок изменяется. То есть здесь нет никого, кто бы выполнял какой либо таск вне потока ивэнт лупа. Но и вы тоже отчасти будете правы если скажете, что функция не синхронная, так как в данном случае мы не можем использовать, например return x, так как функция возвращает свой результат в коллбэке, который в свою очередь будет вызван хоть и синхронно, но после актуального вызова.
Promise.resolve().then(function(){print(1)});
print(2);
На выходе:
2
1
Другое дело, что смыла в этом особого нет, кроме тех случаев, когда нужно решить проблему с сильной загруженностью стека вызовов.
Аналогичная ситуация с await async в .NET.
Асинхронность — это когда функция возвращает управление.а вызываемая сторона потом по своей инициативе дергает некий callback или типа того.
Реальная асинхронка, например, медицинский стандарт DICOM где и SCU и SCP вставляют TCP порты. И когда SCU делает запрос на передачу файла, SCP говорит — команду понял, закрывает соединение, ищет файл. потом открывает свое соединение по TCP и начинает передавать.
мы платим огромным числом обратных вызовов, блокированием основного потока и постоянными потерями контекста
а еще запутаный, нечитаемый и неотлаживаемый код — фиг его знает кто в каком месте повесил какой евент или биндинг.
По своей шкуре знаю как жертва проекта на Flex
Асинхронность в JavaScript: Пособие для тех, кто хочет разобраться