Я вот никак не хотел больше писать статьи, т.к. лениво, да и на работе много интересного. Но сердце все-равно рвется из груди в попытках донести крупицы мудрости (ну или глупости - все зависит от аудитории). И чтобы не растекаться мыслью по древу, перейду к сути...
ВВЕДЕНИЕ
Суть в том, что с какой-то (вроде бы 8.3.18+) версии платформы появились у 1С асинхронные варианты методов для диалоговых окон, копирования файлов, подключения внешних компонент и всего того, что немного раньше делалось при помощи объекта "ОписаниеОповещения", представляющего из себя организацию "промиса" (того самого "обещания" из асинхронного программирования). Но код с "коллбэками" (обратными вызовами) был несколько громоздким. Да, 1С сделала в конфигураторе опцию рефакторинга, который старый синхронный вызов автоматически преобразовывал в новый асинхронный, но все-равно кода стало больше, а больше - это запутаннее. В том же менеджере работы с оборудованием передача "промисов" между функциями существенно затрудняла анализ и обратный инжиниринг для выколупывания протоколов работы с ВК.
Итак, "промисы" в первой итерации от 1С получились громоздкими, запутывали код, превращали его в "спагетти" без всех этих операторов безусловного перехода. И однажды 1С все же решила сделать тот самый await, который сразу и сильно упростил код, возвратив его обратно к линейной последовательности строк.
В своей статье предлагаю рассмотреть подходы к асинхронным диалогам и обращу внимание на некоторые особенности отдельных случаев. Надеюсь, что после прочтения этой статьи Вы перестанете писать "неасинхронно", даже если Ваша конфигурация до сих пор на обычных формах ("моя" - да).
В путь!
ИСТОРИЧЕСКИЙ ЛИКБЕЗ
Когда деревья были большими, а партизаны - толстыми, все программирование было линейным. Код выполнялся строка за строкой. Потом пришел Дейкстра и придумал процедурное программирование. Потом пришел Страуструп и придумал объекты. Нет, я не утверждаю, что это были именно Дейкстра и Страуструп, но они у меня четко так ассоциируются с вот этими двумя эпохами.
Дальше закон Мура стал тормозить, стало активно развиваться параллельное программирование, когда задача решалась сначала на множестве компьютеров, потом на множестве процессоров в одном компьютере, потом на множестве ядер в одном процессоре, а сейчас уже на множестве ядер на ускорителях (видеокартах и прочих специализированных устройствах). Наступила эра параллельного программирования, о которой я писал аж дважды: тыдыщь и тыдыщь.
Ну и где-то тут появилась и асинхронность, как механизм утилизации производительности одного ядра. Т.е. асинхронность - это способность выполнять несколько задач на одном ядре, переключая задачи в моменты ожидания. И вот мне почему-то кажется, что данный момент многие программисты как-то опускают. А ведь компьютер стал достаточно "сложным организмом", в нем помимо центрального процессора есть еще овер дофига других. Сначала это были математические (арифметические) сопроцессоры, с ними все эти процессоры управления памятью и внешними шинами (северные и южные мосты), потом графические ускорители, физические ускорители, тензорные и прочие процессоры для задач "искусственного интеллекта" (перемножения матриц и прочего их преобразования, с чем неплохо справляются и видеокарты - попер маркетинг).
И вот во всем этом море устройств операционная система уже не могла оставаться просто "многопоточной", к многопоточности добавилась асинхронность (в принципе это уже давно так - прерывания рулят), которая потихонечку прописалась в API.
Итак, к чему это я? К тому, чтобы читатель некоторым образом увидел историю развития и ощутил проблемы, которые решались в ходе развития, т.к. согласно ТРИЗ, все улучшения упираются в какие-то ухудшения, появляются качели эффективности, выражающиеся в том, что решение одной проблемы может породить несколько других проблем на другом уровне, которые нужно тоже как-то комплексно решать: разнести во времени (циклы чтения/записи памяти) или пространстве (ядра процессора), поменять отношение (50 градусов - когда-то это была высокая температура для процессора, а сейчас это вообще очень холодно, а 80 градусов стало почти нормой под нагрузкой).
Ну а дальше перейдем к асинхронности 1С.
РАНЬШЕ (за "миллион лет" до н.э.)
В старых версиях платформы обычные формы вполне себе работали с так называемой модальностью - кода открытие диалогов блокирует форму и ждет события с результатом. Выглядело это как-то так:
Результат = ОткрытьФормуМодально(ИмяФормы, Параметры, ...);
Ну и в переменной "Результат" появлялись данные выбора. Для диалогов использовалось что-то типа "Выбрать" или "Ввести" (ВвестиСтроку/Число/Дату/Значение). Таким образом код останавливался и ждал, когда пользователь что-то выберет, после чего можно было бы спокойно и без нервотрепки обработать результат.
Какие у этого минусы? Да, собственно, никаких для обычного разработчика. В то, что 1С не смогла прилично реализовать это для веб-клиента, я не верю. Единственный, на мой скромный взгляд, смысл в этом только как следование за трендами. Но в части диалогов модальный вызов ничем не отличается от немодального. В части подключения внешних компонент это уже оправдано, т.к. они вполне могут ожидать какие-то данные от оборудования при инициализации, которые при асинхронном подходе действительно будут сокращать время запуска 1С. То же самое и с копированием файлов - это позволяет пользователю не ждать завершения их копирования и перейти к другим задачам. Но тут экономия времени минимальна.
ПЕРВЫЙ БЛИН...
Да, первая реализация асинхронности была так себе - код стал запутанным. Функции "Выбрать*" превратились в "ПоказатьВыбор*", функции "Ввести*" в "ПоказатьВвод*", в "ОткрытьФорму" появилась возможность получить и обработать результат выбора с помощью отдельной процедуры, которая могла располагаться не только в форме, но и в общем модуле. Но для всего этого потребовалось писать еще одну процедуру на каждый диалог выбора/ввода/формы. В части кода, то он мог быть сгеренирован платформой, но его просто тупо становилось больше. Зато многие получили и профит - писали одну процедуру на множество диалогов, а иногда даже выносили это в отдельный модуль. В общем помимо проблем такой подход породил и новые возможности организации кода, его структурирования.
В общем, был ли этот блин комом или нет - решать вам, господа и товарищи читатели.
АСИНХ
И вот появился тот самый Асинх, ради которого я снова решил писать много букв. С одной стороны, этот суффикс получили все старые диалоговые методы/функции. Т.е. вот как-то так менялись названия: "Выбор*" -> "ПоказатьВыбор*" -> "Выбор*Асинх". Помимо этого у процедур и функций появился префикс "Асинх", который указывает, что процедура асинхронная.
Давайте разберемся с тем, как теперь это работает. Я, например, не увидел понимания этого у многих своих коллег, поэтому даже планирую провести на эту тему внутреннее обучение.
Итак, работает это все просто.
1. Вы вызываете асинхронную функцию.
2. Асинхронная функция помещается в очередь на выполнение.
3. Вместо результата планировщик (или как его там назвать) возвращает объект типа "Обещание" (промис), фактически адрес структуры состояния функции.
4. Чтобы получить результат, вам надо подождать. В 1С сделали тот самый "Ждать Обещание".
И вроде бы что это дает? Да вот нифига пока* не дает, но позволяет вернуться к старому, т.е. делать все почти также, как делали это в стародревние времена.
* Жду асинхронных запросов к HTTP-сервисам - там резон действительно есть.
ПРИМЕРЫ
Давайте разберем "исторические" примеры превращения кода из модального в асинхронный.
Модальный код:
Диалог = Новый ДиалогВыбораФайлов(Режим);
Если Диалог.Выбрать() Тогда
ИмяФайла = Диалог.ПолноеИмяФайла;
КонецЕсли;
Код с описанием оповещения:
Диалог = Новый ДиалогВыбораФайлов(Режим);
Диалог.Показать(Новый ОписаниеОповещения("ПриВыбореФайла", "ЭтаФорма", ДополнительныеПараметры));
...
&НаКлиенте
Процедура ПриВыбореФайла(Результат, ДополнительныеПараметры) Экспорт
Если ЗначениеЗаполнено(Результат) Тогда
ИмяФайла = Результат[0];
КонецЕсли;
КонецПроцедуры
Код увеличился, появилась еще одна процедура. Благо, что ее можно было засунуть хоть в общий модуль и вообще сделать одну процедуру на все случаи жизни.
Асинхронно:
&НаКлиенте
Асинх Процедура ВыбратьИмяФайла(Команда)
Диалог = Новый ДиалогВыбораФайлов(Режим);
Результат = Ждать Диалог.ВыбратьАсинх();
Если ЗначениеЗаполнено(Результат) Тогда
ИмяФайла = Результат[0];
КонецЕсли;
КонецПроцедуры
Смотрите, если мы вызываем этот код, как команду, то в стандартной процедуре обработки команды нужно прописать префикс "Асинх". Это связано с тем, что оператор "Ждать" можно вызывать только в асинхронных процедурах и функциях.
Кстати, смотрел один ролик, в котором автор говорил, что смысла в асинхронных процедурах вроде как нет, ибо "Ждать" возвращает результат обещания, а он имеет смысл только в функциях. Я, лично, считаю наоборот, т.к. "самописная" асинхронная функция ничего не дает, если внутри нее не вызывается асинхронный диалог или копирование файлов, подключение внешних компонент и все такое прочее асинхронное. А вот асинхронная процедура позволяет использовать "Ждать"*.
1С: Асинх / Async представляет собой модификатор, который может применяться к процедуре или функции, написанной на встроенном языке. Использование данного модификатора делает процедуру или функцию асинхронной. Важной особенностью является также то, что оператор Ждать может использоваться только внутри Асинх процедур/функций.
Т.е. у нас "Ждать" из обычной процедуры вызвать нельзя, поэтому процедуры обработки событий формы (команд и прочих мест), которые предполагают использование асинхронных диалогов, должны теперь быть с префиксом "Асинх". Городить дополнительные функции для этого не нужно.
Кстати, заметил, что если в диалоге нажать отмену, то код после "Ждать" не выполняется. Таким образом можно вообще не проверять переменную на заполненность, а отмена выбора в цепочке вопросов приведет к дальнейшей отмене всей оставшейся цепочки. Но тут могу быть неправ - проверяйте.
ОСОБЕННОСТИ
Основной особенностью новой жизни (ну помимо дописывания префикса "Асинх" к событиям формы) является то, что 1С будет исполнять асинхронную функцию уже после того, как отработает "базовое событие" формы. Что под этим подразумевается? То, что если у вас есть событие с аргументом "СтандартнаяОбработка", то вне зависимости от того, что там внутри этого кода произошло, система после выхода из процедуры будет смотреть на этот флаг, и если он в Истина, то будет произведена стандартная отработка. Например, для таблицы значений будет открыто значение, для табличного документа тоже. С асинхронными функциями сложнее, т.к. они будут работать уже после того, как стандартное событие отработает. И если Вы внутри такой функции поставите "СтандартнаяОбработка = ложь", то система это не увидит, ибо она обработает стандартное событие до того, как асинхронная функция вернет хоть какой-то результат.
Как бороться? Правильно, вызывать асинхронную процедуру из синхронного обработчика событий.
ВЫВОД
Основной вывод: опять получилось букв больше, чем хотелось бы. Ну и второй вывод: юзайте асинхронные диалоги, т.к. они экономят строки кода.
ВСЕМ ДОБРА!
