Сообщение Re[12]: Обработка ошибок от 11.10.2017 19:00
Изменено 11.10.2017 19:02 vdimas
Re[12]: Обработка ошибок
Здравствуйте, vsb, Вы писали:
MTD>>Вот это и есть синхронный код, да он притворяется асинхронным, но сущность его именно такова.
vsb>Всё наоборот. Это асинхронный код, который притворяется синхронным.
И опять неверно. ))
Это кооперативная многозадачность вместо вытесняющей.
Приведенный код синхронный, разумеется, ничего асинхронного в нём нет.
>> В настоящем асинхронном коде таких явных точек синхронизации нет
Вот еще. А если я использую библиотеку кооперативной многозадачности? Например, как в Windows 3.x при вызове любой операции ввода-вывода? Там абсолютно то же самое происходило, только не надо было явно указывать await. Т.е. весь ввод-вывод был синхронный для логического потока исполнения, но асинхронный в "масштабе" компьютера.
vsb>после выполнения операции вызывается обработчик — это позволяет лучше нагрузить процессор не тратя время на ожидание.
Процессор и не тратит время на ожидание.
Вся дикость вот этого сниппета const x = await something() имеет корнями высокую цену ядерных переключений потоков в СОВРЕМЕННЫХ процах с защищённой памятью и ничего более. Если бы ядро ОС переключало потоки с достаточной эффективностью, то можно было бы ожидать выполнение операции something ср-вами самой ОС (через хендл асинхронной операции). Но такой код ведь зовут синхронным, верно?
vsb>Это не точка синхронизации. Это указание кода, который будет выполнен при получении результата.
Это и есть точка синхронизации задач прямо по-определению.
Дотнетный Task — это всего-навсего юзер-спейсный аналог процесса (потока) и ничего более.
vsb>Собственно поинт в том, что если в языке есть удобные средства для работы с асинхронным кодом
Нету. Приведенный код — не асинхронный.
Прибит гвоздями к объекту Task, который сам по себе достаточно тяжеловесен.
А необходимость объявлять окружающий этот сниппет метод как async — так вообще дичь и ха-ха 3 раза. ))
Для сравнения, ни одна нейтивная библиотека кооперативной многозадачности этого не требует.
Кароч, это всё нубство на ровном месте. Костыль на безрыбье, чтобы раком не встать.
vsb>(в JavaScript, Kotlin, вроде в C# тоже такое есть), то исключения прекрасно подходят для работы с ошибками. Если таких средств нет, с асинхронным кодом работать очень неудобно в любом случае.
В дотнете и так неудобно с асинхронным кодом работать. Например, ты не может написать свой независимый механизм кооперативной диспетчеризации и использовать его аналогично ср-вами языка. Ну вот не нравятся мне тяжеловесные и тупые Task, у меня есть своя легковесная lock-free реализация Promise/Future, которая на порядки удобней (потому что сам этот подход хорошо проработан во многих языках). Вот как мне использовать продолжения от моих Future в аналогичном синтаксисе await, ы? )) Аж никак. Только явно описывать продолжения на анонимных ф-иях, что есть дичь. Но зато это будет тот самый настоящий асинхронный код, со всеми его "плюшками" (в плохом смысле этого слова).
MTD>>Вот это и есть синхронный код, да он притворяется асинхронным, но сущность его именно такова.
vsb>Всё наоборот. Это асинхронный код, который притворяется синхронным.
И опять неверно. ))
Это кооперативная многозадачность вместо вытесняющей.
Приведенный код синхронный, разумеется, ничего асинхронного в нём нет.
>> В настоящем асинхронном коде таких явных точек синхронизации нет
Вот еще. А если я использую библиотеку кооперативной многозадачности? Например, как в Windows 3.x при вызове любой операции ввода-вывода? Там абсолютно то же самое происходило, только не надо было явно указывать await. Т.е. весь ввод-вывод был синхронный для логического потока исполнения, но асинхронный в "масштабе" компьютера.
vsb>после выполнения операции вызывается обработчик — это позволяет лучше нагрузить процессор не тратя время на ожидание.
Процессор и не тратит время на ожидание.
Вся дикость вот этого сниппета const x = await something() имеет корнями высокую цену ядерных переключений потоков в СОВРЕМЕННЫХ процах с защищённой памятью и ничего более. Если бы ядро ОС переключало потоки с достаточной эффективностью, то можно было бы ожидать выполнение операции something ср-вами самой ОС (через хендл асинхронной операции). Но такой код ведь зовут синхронным, верно?
vsb>Это не точка синхронизации. Это указание кода, который будет выполнен при получении результата.
Это и есть точка синхронизации задач прямо по-определению.
Дотнетный Task — это всего-навсего юзер-спейсный аналог процесса (потока) и ничего более.
vsb>Собственно поинт в том, что если в языке есть удобные средства для работы с асинхронным кодом
Нету. Приведенный код — не асинхронный.
Прибит гвоздями к объекту Task, который сам по себе достаточно тяжеловесен.
А необходимость объявлять окружающий этот сниппет метод как async — так вообще дичь и ха-ха 3 раза. ))
Для сравнения, ни одна нейтивная библиотека кооперативной многозадачности этого не требует.
Кароч, это всё нубство на ровном месте. Костыль на безрыбье, чтобы раком не встать.
vsb>(в JavaScript, Kotlin, вроде в C# тоже такое есть), то исключения прекрасно подходят для работы с ошибками. Если таких средств нет, с асинхронным кодом работать очень неудобно в любом случае.
В дотнете и так неудобно с асинхронным кодом работать. Например, ты не может написать свой независимый механизм кооперативной диспетчеризации и использовать его аналогично ср-вами языка. Ну вот не нравятся мне тяжеловесные и тупые Task, у меня есть своя легковесная lock-free реализация Promise/Future, которая на порядки удобней (потому что сам этот подход хорошо проработан во многих языках). Вот как мне использовать продолжения от моих Future в аналогичном синтаксисе await, ы? )) Аж никак. Только явно описывать продолжения на анонимных ф-иях, что есть дичь.
Но зато это будет тот самый настоящий асинхронный код, со всеми его "плюшками" (в плохом смысле этого слова).Re[12]: Обработка ошибок
Здравствуйте, vsb, Вы писали:
MTD>>Вот это и есть синхронный код, да он притворяется асинхронным, но сущность его именно такова.
vsb>Всё наоборот. Это асинхронный код, который притворяется синхронным.
И опять неверно. ))
Это кооперативная многозадачность вместо вытесняющей.
Приведенный код синхронный, разумеется, ничего асинхронного в нём нет.
>> В настоящем асинхронном коде таких явных точек синхронизации нет
Вот еще. А если я использую библиотеку кооперативной многозадачности? Например, как в Windows 3.x при вызове любой операции ввода-вывода? Там абсолютно то же самое происходило, только не надо было явно указывать await. Т.е. весь ввод-вывод был синхронный для логического потока исполнения, но асинхронный в "масштабе" компьютера.
vsb>после выполнения операции вызывается обработчик — это позволяет лучше нагрузить процессор не тратя время на ожидание.
Процессор и не тратит время на ожидание.
Вся дикость вот этого сниппета const x = await something() имеет корнями высокую цену ядерных переключений потоков в СОВРЕМЕННЫХ процах с защищённой памятью и ничего более. Если бы ядро ОС переключало потоки с достаточной эффективностью, то можно было бы ожидать выполнение операции something ср-вами самой ОС (через хендл асинхронной операции). Но такой код ведь зовут синхронным, верно?
vsb>Это не точка синхронизации. Это указание кода, который будет выполнен при получении результата.
Это и есть точка синхронизации задач прямо по-определению.
Дотнетный Task — это всего-навсего юзер-спейсный аналог процесса (потока) и ничего более.
vsb>Собственно поинт в том, что если в языке есть удобные средства для работы с асинхронным кодом
Нету. Приведенный код — не асинхронный.
Прибит гвоздями к объекту Task, который сам по себе достаточно тяжеловесен.
А необходимость объявлять окружающий этот сниппет метод как async — так вообще дичь и ха-ха 3 раза. ))
Для сравнения, ни одна нейтивная библиотека кооперативной многозадачности этого не требует.
Кароч, это всё нубство на ровном месте. Костыль на безрыбье, чтобы раком не встать.
vsb>(в JavaScript, Kotlin, вроде в C# тоже такое есть), то исключения прекрасно подходят для работы с ошибками. Если таких средств нет, с асинхронным кодом работать очень неудобно в любом случае.
В дотнете и так неудобно с асинхронным кодом работать. Например, ты не можешь написать свой независимый механизм кооперативной диспетчеризации и использовать его аналогично ср-вами языка. Ну вот не нравятся мне тяжеловесные и тупые Task, у меня есть своя легковесная lock-free реализация Promise/Future, которая на порядки удобней (потому что сам этот подход хорошо проработан во многих языках). Вот как мне использовать продолжения от моих Future в аналогичном синтаксисе await, ы? )) Аж никак. Только явно описывать продолжения на анонимных ф-иях, что есть дичь. Но зато это будет тот самый настоящий асинхронный код, со всеми его "плюшками" (в плохом смысле этого слова).
MTD>>Вот это и есть синхронный код, да он притворяется асинхронным, но сущность его именно такова.
vsb>Всё наоборот. Это асинхронный код, который притворяется синхронным.
И опять неверно. ))
Это кооперативная многозадачность вместо вытесняющей.
Приведенный код синхронный, разумеется, ничего асинхронного в нём нет.
>> В настоящем асинхронном коде таких явных точек синхронизации нет
Вот еще. А если я использую библиотеку кооперативной многозадачности? Например, как в Windows 3.x при вызове любой операции ввода-вывода? Там абсолютно то же самое происходило, только не надо было явно указывать await. Т.е. весь ввод-вывод был синхронный для логического потока исполнения, но асинхронный в "масштабе" компьютера.
vsb>после выполнения операции вызывается обработчик — это позволяет лучше нагрузить процессор не тратя время на ожидание.
Процессор и не тратит время на ожидание.
Вся дикость вот этого сниппета const x = await something() имеет корнями высокую цену ядерных переключений потоков в СОВРЕМЕННЫХ процах с защищённой памятью и ничего более. Если бы ядро ОС переключало потоки с достаточной эффективностью, то можно было бы ожидать выполнение операции something ср-вами самой ОС (через хендл асинхронной операции). Но такой код ведь зовут синхронным, верно?
vsb>Это не точка синхронизации. Это указание кода, который будет выполнен при получении результата.
Это и есть точка синхронизации задач прямо по-определению.
Дотнетный Task — это всего-навсего юзер-спейсный аналог процесса (потока) и ничего более.
vsb>Собственно поинт в том, что если в языке есть удобные средства для работы с асинхронным кодом
Нету. Приведенный код — не асинхронный.
Прибит гвоздями к объекту Task, который сам по себе достаточно тяжеловесен.
А необходимость объявлять окружающий этот сниппет метод как async — так вообще дичь и ха-ха 3 раза. ))
Для сравнения, ни одна нейтивная библиотека кооперативной многозадачности этого не требует.
Кароч, это всё нубство на ровном месте. Костыль на безрыбье, чтобы раком не встать.
vsb>(в JavaScript, Kotlin, вроде в C# тоже такое есть), то исключения прекрасно подходят для работы с ошибками. Если таких средств нет, с асинхронным кодом работать очень неудобно в любом случае.
В дотнете и так неудобно с асинхронным кодом работать. Например, ты не можешь написать свой независимый механизм кооперативной диспетчеризации и использовать его аналогично ср-вами языка. Ну вот не нравятся мне тяжеловесные и тупые Task, у меня есть своя легковесная lock-free реализация Promise/Future, которая на порядки удобней (потому что сам этот подход хорошо проработан во многих языках). Вот как мне использовать продолжения от моих Future в аналогичном синтаксисе await, ы? )) Аж никак. Только явно описывать продолжения на анонимных ф-иях, что есть дичь.
Но зато это будет тот самый настоящий асинхронный код, со всеми его "плюшками" (в плохом смысле этого слова).