Комментарии 35
Без сомнений, async/await очень хороши, хотя лично по моему мнению ключевое слово
async излишне — мне кажется, что рай на земле наступил бы мгновенно после того, как все функции стали бы неявно async-овыми. В первую очередь я думаю о трапах Proxy — чтобы можно было сделать, скажем, proxy.foo = 123, и это вызвало асинхронный обработчик, который мог бы сколько угодно блокировать вызывающий контекст — пока сходит в интернет, пока скажет, что значение свойства foo обновилось, пока вернется обратно. Полная синхронная семантика.
… промах
↓
Вы, фактически, предлагаете сделать javascript многопоточным языком. Но тогда возникнут проблемы с синхронизацией потоков — если любое присваивание может оказаться асинхронным и переключить контекст исполнения — как вообще писать алгоритмы?
Нет, я понимаю, что такие способы есть — пишут же как-то на плюсах :) Но именно однопоточность javascript — ключевая характеристика языка.
Нет, я понимаю, что такие способы есть — пишут же как-то на плюсах :) Но именно однопоточность javascript — ключевая характеристика языка.
Нет, асинхронность не подразумевает многопоточности. Генераторы ведь не создают многопоточность. Я прошу о мелочи — об изменении семантики доступа к аттрибутам на асинхронную :) Т.е. чтобы присваивания вида
foo.bar = 123 были типа как await foo.setAttr('bar', 123). Ну или, если более многословно и не так корректно, foo.setAttr('bar', 123, (function() { продолжение функции }).bind(this)).
Чем тотальная неявная асинхронность отличается от многопоточности на одноядерном процессоре?
Гонки и ошибки синхронизации вполне себе возможны и на одном ядре.
Гонки и ошибки синхронизации вполне себе возможны и на одном ядре.
1. откуда берется неявность? Многопоточность — это вытесняющая многозадачность. Асинхронность — это кооперативная многозадачность. В первом случае поток прерывает свое выполнение неявно, в любой момент, который покажется удобным планировщику. Во втором случае поток явно возвращает управление планировщику — в моем случае при обращении к какому-либо аттрибуту.
2. подскажите, какие могут быть «ошибки синхронизации», когда у вас физически один поток? Т.е. не много потоков на одноядерном процессоре, как вы подразумеваете, а один поток с одной очередью сообщений, как это происходит в JS. Правильный ответ — никаких race conditions и ошибок синхронизации быть не может принципиально, по той же причине, по которой их не может быть в coroutines.
2. подскажите, какие могут быть «ошибки синхронизации», когда у вас физически один поток? Т.е. не много потоков на одноядерном процессоре, как вы подразумеваете, а один поток с одной очередью сообщений, как это происходит в JS. Правильный ответ — никаких race conditions и ошибок синхронизации быть не может принципиально, по той же причине, по которой их не может быть в coroutines.
Ну вот запустили вы код:
Это *условно* эквивалентно чему-то вроде
Одновременно с этим кодом некто запустил
Что можно записать как
А теперь вопросы на засыпку.
В каком порядке функции f1, f2, f3, f4 могут выполниться?
Будет ли результат их выполнения зависеть от порядка?
Каков будет результат, если порядок вызова будет f1 -> f3 -> f2 -> f4?
Как по-умному называются такие ошибки (подсказка: race...)?
x.alpha += x.beta
Это *условно* эквивалентно чему-то вроде
x.getAttr('alpha', function(alpha) { // f1
y.getAttr('beta', function(beta) { // f2
x.setAttr('alpha', alpha + beta, function() {
// do nothing
}
}
}
Одновременно с этим кодом некто запустил
x.alpha -= x.gamma
Что можно записать как
x.getAttr('alpha', function(alpha) { // f3
y.getAttr('gamma', function(gamma) { // f4
x.setAttr('alpha', alpha - gamma, function() {
// do nothing
}
}
}
А теперь вопросы на засыпку.
В каком порядке функции f1, f2, f3, f4 могут выполниться?
Будет ли результат их выполнения зависеть от порядка?
Каков будет результат, если порядок вызова будет f1 -> f3 -> f2 -> f4?
Как по-умному называются такие ошибки (подсказка: race...)?
это же хорошо, быть уверенным, что между соседними операциями не вклинится еще чего, а то вдруг пока мы будем ждать, где-нибудь этот самый proxy удалится
Ну да, однопоточная природа JS гарантирует, что никто между соседними операциями не вклинится таким образом, чтобы proxy взял и удалился. Потому что, как минимум, на него есть ссылка в контексте функции, которая ждет завершения асинхронного коллбэка. А так, чтобы просто взял и вклинился и сделал что-то свое — ну так в этом вся суть асинхронного программирования. Чтобы не кто-то один в одно рыло все делал, а каждый, когда появляется возможность, брал и вклинивался максимально детерминированным способом. Почему подобные аргументы не применяются по отношению к коллбэкам, промисам или генераторам? Там везде все постоянно вклиниваются, и объекты из-за этого меняются, и в этом и есть весь смысл.
Возможно, у вас могло сложиться впечатление, что «вклинивание» происходит недетерминированно, сродни вытесняющей многозадачности. Нет. Присванивание поля вызывает трап прокси, который является обыкновенной функцией, и которая затем должна вернуть значение. Уже сейчас можно вклиниться в процесс обычного присвания. Я лишь предлагаю сделать еще один шаг и сделать допустимым асинхронную обработку трапов в духе современного JS.
Возможно, у вас могло сложиться впечатление, что «вклинивание» происходит недетерминированно, сродни вытесняющей многозадачности. Нет. Присванивание поля вызывает трап прокси, который является обыкновенной функцией, и которая затем должна вернуть значение. Уже сейчас можно вклиниться в процесс обычного присвания. Я лишь предлагаю сделать еще один шаг и сделать допустимым асинхронную обработку трапов в духе современного JS.
Почему подобные аргументы не применяются по отношению к коллбэкам, промисам или генераторам?потому что все явно, это ожидаемое поведение
Ну так и тут все явно. Где неявность-то, объясните слепому? Почему __setattr__ в Python — это явно, а set trap в ES6 Proxy — неявно? Почему промис — это явно, а тот же промис, но вызванный в обработчике события — это неявно? Глупости и ложные выводы, напрямую следующие из непонимания основополагающих принципов Javascript.
Почему __setattr__ в Python — это явно, а set trap в ES6 Proxy — неявно?не знаю, не достаточно в теме
вы хотите, чтобы асинхронный код был неотличим от синхронного, и вообще, пример с сеттером показывает сопрограммы как-то не с той стороны
основополагающих принципов Javascriptпринципы в студию
Уже сейчас можно вклиниться в процесс обычного присвания.Как именно? Думал, что исполняемый кусок кода не прерывается, а события обрабатываются, когда никакой другой код не исполняется. Именно это подразумевал под ожидаемым поведением. А если в каком-то месте ожидание события, то значит, там могут обработаться и другие события(собственно без этого нет и плюсов по сравнению с обычным синхронным вариантом), то есть нарушается атомарность(как будто все выполняется в критических секциях).
Если бы все функции были бы асинхронными сильно ухудшилось бы применение NodeJS как script'ового языка именно для решения каких-то задач, где и нужна асинхронность, но на самом деле она нужна ровно в одном месте, где-то где перемалываются большие куски данных или происходит какая-то важная асинхронная часть. С моей точки зрения сейчас все NodeJS модули вместо калбэков должны уметь в Promise, потому что стандартом стало уже написание на промисах + добавление больше синхронных функций, чтобы проще было писать код для тулзов. Впрочем внедрение await async уберет эти проблемы при написание тулзов.
Хотя если копать глубже то такой подход на самом деле используется только на уровне NodeJS, которая и делает асинхронное взаимодействие, но не через паузу content'а, а через eventloop. Получается сама NodeJS успела устареть и не поспевает за скоростью разработки v8 js'а. Т.е. в принципе в этой ситуации понятно, что NodeJS играет роль догоняющего, фактически генераторы дают этакую паузу контента уже сейчас осталось только это где-то внедрить по грамотнее, наверное тоже ожидают, что на основе генераторах сделают async/await.
В принципе update'ить структуру данных можно, только тогда set'еры должны возвращать Promise'ы. Плюс можно сделать что-то типа lazy getter'ов, которые бы тоже ходили куда-то или не ходили но в любом случае вернули Promise, в принципе для этого конечно больше подходят future'ы тогда, но пока они не реализованы в принципе можно и по promise'ам резолвить. В принципе если все по итогу будет возвращать Promise'ы то станет гораздо легче, нужно только выработать какой-то стандарт отлова синхронных ошибок, т.к. в каждом промисе нужно писать еще try{ } catch{} и catch для ошибок пришедших из предыдущего Promise'а.
Хотя если копать глубже то такой подход на самом деле используется только на уровне NodeJS, которая и делает асинхронное взаимодействие, но не через паузу content'а, а через eventloop. Получается сама NodeJS успела устареть и не поспевает за скоростью разработки v8 js'а. Т.е. в принципе в этой ситуации понятно, что NodeJS играет роль догоняющего, фактически генераторы дают этакую паузу контента уже сейчас осталось только это где-то внедрить по грамотнее, наверное тоже ожидают, что на основе генераторах сделают async/await.
В принципе update'ить структуру данных можно, только тогда set'еры должны возвращать Promise'ы. Плюс можно сделать что-то типа lazy getter'ов, которые бы тоже ходили куда-то или не ходили но в любом случае вернули Promise, в принципе для этого конечно больше подходят future'ы тогда, но пока они не реализованы в принципе можно и по promise'ам резолвить. В принципе если все по итогу будет возвращать Promise'ы то станет гораздо легче, нужно только выработать какой-то стандарт отлова синхронных ошибок, т.к. в каждом промисе нужно писать еще try{ } catch{} и catch для ошибок пришедших из предыдущего Promise'а.
Ну вот я о том и говорю, чтобы фактически всегда возвращать промисы, принимать промисы, и вообще, сделать так, что любая функция всегда возвращает промис — а уж когда она вернет настоящее значение и зарезолвит промис, который она вернула сразу — дело времени. И делать все это, естественно, автомагически.
А вы в продакшене уже используете генераторы или es7 transpiler? Я пока опасался за рост стэка, но потом понял, что через Promise'ы event loop stack не растет, раньше пользовался iced-coffeescript, но там опыт был печальный из-за довольно грустной на те времена реализации подобного подхода, так что я пока опасался. Впрочем код написанный с es7 transpiler все равно меня пугает, но co вполне приятный подход дает.
:) Уже давно клинки сточили о «тяжелые сеттеры», а вы ещё предлагаете асинхронные действия проводить. Рай, он может так со стороны кажеться, а оказавшись там — увидите, что код станет абсолютно не предсказуем. Явное лучше неявного, особенно в js.
вы ещё предлагаете асинхронные действия проводить
А вы предлагаете все действия проводить синхронно, блокируя поток в однопоточном JS? :)
Рай, он может так со стороны кажеться, а оказавшись там — увидите, что код станет абсолютно не предсказуем.
Вы считаете лапшу из коллбэков более предсказуемой, чем
async / await и обещания? Сразу видно, что это вы смотрите со стороны. Предположим, десяток последовательных асинхронных задач, необработанная ошибка в одном коллбэке — и всё перестаёт работать, когда с async / await достаточно всё обернуть в один try / catch.Похоже вышло недопонимание.
Я предлагаю совсем не проводить никаких тяжёлых действий в сеттерах.
Между каких строк вы это увидели? :). Совсем нет, но автор комментария предлагает вовсе отказаться от ключевых слов — async/await, и в дополнение речь шла не только о асинхронных функциях, но и сеттерах.
> А вы предлагаете все действия проводить синхронно, блокируя поток в однопоточном JS? :) Я предлагаю совсем не проводить никаких тяжёлых действий в сеттерах.
> Вы считаете лапшу из коллбэков более предсказуемой, чем async / await и обещания? Между каких строк вы это увидели? :). Совсем нет, но автор комментария предлагает вовсе отказаться от ключевых слов — async/await, и в дополнение речь шла не только о асинхронных функциях, но и сеттерах.
Категорически не согласен. Например, мы пишем красивый удобный freestyle ORB со следующим интерфейсом — сервер расшаривает какой-то объект, а клиенты обращаются к этому объекту так, как будто бы он локальный. Т.е. вызывают у него методы, читают свойства, пишут аттрибуты, итерируются по нему, вызывают его в явном виде, если он функция, делают на нем
Когда любой объект нужно передать куда-нибудь по сети, мы назначаем этому объекту новый UUID, предварительно проверив в локальной слабой карте, что для этого объекта UUID еще нет. И вместо объекта, отправляем получателю только UUID. На принимающей стороне UUID заменяется на ES6 Proxy с вшитым идентификатором, любой чих отправляющий владельцу объекта. Подвох в том, что у того же трапа
1. забыть, понять и простить. Плюс — просто в реализации, просто не нужно ничего делать. Минус — ничего не работает.
2. синхронный XMLHttpRequest. Плюс — работает. Минус — лучи мягкого стула от других разработчиков за блокирование очереди событий.
3. использовать асинхронную семантику трапов. Плюс — то, что нужно. Минус — пока ES7 не стал стандартом, не понятно, будет ли такое возможно.
В третьем, последнем случае, если бы async/await еще не существовало, сигнатура могла бы вместо value возвращать Promise, а реализация бы просто не возвращалась к месту сработки трапа, пока Promise не зарезолвится. Но если функцию трапа можно будет объявить, как async, то это тоже будет хорошо.
Если вы знаете, как другим способом сделать подобное — буду рад услышать. Из того, что мне приходило в голову альтернативного — отказ от несериализуемых объектов, конвертация всего в JSON, отказ от геттеров-сеттеров и оперирование исключительно функциями, исключительно асинхронными, принимающими коллбэк в качестве параметра. Ну а это уже совсем не красивый и элегантный ORB, а dnode какой-то, простите.
new и т.д. Как этого достичь?Когда любой объект нужно передать куда-нибудь по сети, мы назначаем этому объекту новый UUID, предварительно проверив в локальной слабой карте, что для этого объекта UUID еще нет. И вместо объекта, отправляем получателю только UUID. На принимающей стороне UUID заменяется на ES6 Proxy с вшитым идентификатором, любой чих отправляющий владельцу объекта. Подвох в том, что у того же трапа
get вот такая сигнатура — (target, name, proxy): value. Т.е. ответ от нас ожидается сразу же, но у нас его нет — он где-то на другом компьютере, далеко. Есть три варианта:1. забыть, понять и простить. Плюс — просто в реализации, просто не нужно ничего делать. Минус — ничего не работает.
2. синхронный XMLHttpRequest. Плюс — работает. Минус — лучи мягкого стула от других разработчиков за блокирование очереди событий.
3. использовать асинхронную семантику трапов. Плюс — то, что нужно. Минус — пока ES7 не стал стандартом, не понятно, будет ли такое возможно.
В третьем, последнем случае, если бы async/await еще не существовало, сигнатура могла бы вместо value возвращать Promise, а реализация бы просто не возвращалась к месту сработки трапа, пока Promise не зарезолвится. Но если функцию трапа можно будет объявить, как async, то это тоже будет хорошо.
Если вы знаете, как другим способом сделать подобное — буду рад услышать. Из того, что мне приходило в голову альтернативного — отказ от несериализуемых объектов, конвертация всего в JSON, отказ от геттеров-сеттеров и оперирование исключительно функциями, исключительно асинхронными, принимающими коллбэк в качестве параметра. Ну а это уже совсем не красивый и элегантный ORB, а dnode какой-то, простите.
мне кажется, вы хотите переизобрести DCOM только для js
как насчет варианта синхронный XMLHttpRequest в worker?
как насчет варианта синхронный XMLHttpRequest в worker?
Ну, вообще нет — из-за отсутствия интерфейса объектов. С другой стороны, если представить proxy в виде жесткого интерфейса, то очень похоже, т.к. я COM-ом вдохновлялся. Мне показалось элегантным решение без объявления вообще чего бы то ни было и, что важно, без необходимости сериализовывать что-либо, отличное от примитивных типов.
Синхронный XHR в воркере не сработает по той причине, что с воркером нужно общаться — а с ним можно общаться только асинхронно через postmessage. Шило на мыло, увы. Либо синхронный XHR (медленно и печально), либо асинхронные трапы (если они будут сделаны), тут иначе никак, увы.
Синхронный XHR в воркере не сработает по той причине, что с воркером нужно общаться — а с ним можно общаться только асинхронно через postmessage. Шило на мыло, увы. Либо синхронный XHR (медленно и печально), либо асинхронные трапы (если они будут сделаны), тут иначе никак, увы.
что скажете по поводу добавления уровня абстракции. создаем очередь из действий и ожидаемых событий, аналог expect:
spawn()
.send(target, 'insert', {id: value})
.do(log("inserting..."))
.expect(target, 'inserted', function(result){log(result)})
.do(log("inserted."))
.wait(100)
.start()
Я понимаю, что вы хотите сделать, но вы через чур вдаетесь в детали — нужно подняться немного выше)
— Сеттеры/Геттеры — по моему опыту, они должны быть очень легкими, лишь манипуляция полями своего объекта и отсылка событий, в противном случае код и архитектура становятся запутанными и не явными.
— Методы — вот здесь имеет место разговор о асинхронности, но что при этом выполняется абсолютно не важно, потому что абстракции предполагают что мы можем, например, использовать разный транспорт для сохранения объекта. И не важно будь то удалённый вызов процедур, запись в локальную базу или ещё что-то там.
Как для меня, самым лучшим вариантом является ваш третий вариант, но модифицирован — Promise но с async/await. Также как сейчас в C#
— Сеттеры/Геттеры — по моему опыту, они должны быть очень легкими, лишь манипуляция полями своего объекта и отсылка событий, в противном случае код и архитектура становятся запутанными и не явными.
— Методы — вот здесь имеет место разговор о асинхронности, но что при этом выполняется абсолютно не важно, потому что абстракции предполагают что мы можем, например, использовать разный транспорт для сохранения объекта. И не важно будь то удалённый вызов процедур, запись в локальную базу или ещё что-то там.
Как для меня, самым лучшим вариантом является ваш третий вариант, но модифицирован — Promise но с async/await. Также как сейчас в C#
Task<T> var user = await Service.Fetch(params);. ES7 движется в этом направлении, и с traceur уже можно с этим играться.
Библиотека для coroutine ruff делает то же, что и Co. Только проще: без промисов, но с ивентами.
А еще она работает в браузере без необходимости использовать browserify.
А еще она работает в браузере без необходимости использовать browserify.
В NodeJS конкретно эту бы имплементацию вам бы не советовал бы использовать. Она не использует EventEmitter. Но для браузера наверное нормально.
Что плохого в том, что эта имплементация не использует EventEmitter?
Ну там костыль со всеми вытекающими. Нельзя отписаться от event'а или перезаписать его и черт его знает как у его имплементации с оптимизацией, уже вижу что он использует forEach, что довольно неплохой удар по оптимизиации. Все таки пользоваться стандартной библиотекой для бэкэнда имеет больше смысла. Для фронта конечно ok.
Пожалуй вы правы, в версии 1.3.0 учтены ваши замечения.
<shameless-plug>
А я давно уже такое использую: asjs
Ну и в разных популярных препроцессорах уже появилось, так что мне непонятно, зачем люди всё ещё лепят лапшу из колбэков и then-ов…
А я давно уже такое использую: asjs
Ну и в разных популярных препроцессорах уже появилось, так что мне непонятно, зачем люди всё ещё лепят лапшу из колбэков и then-ов…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Имплементация coroutine в NodeJS