Механизм подключения обработчика ожидания известен с 8.0, описан в Синтакс-помощнике и десятках публикаций. По сути, это механизм, реализующий псевдо-параллельный вызов процедур клиентского контекста сеанса с заданной периодичностью либо однократно.
С точки зрения языка 1С, это две процедуры глобального контекста сеанса: ПодключитьОбработчикОжидания и ОтключитьОбработчикОжидания. Пересказывать хелп не будем, отметим только, что сложился стереотип, будто однократность применима лишь для таймаута менее 1 секунды; но реально однократный вызов может использовать любой таймаут.
С точки зрения платформы, это поддерживаемая процессом rphost, единая для сеанса, виртуальная таблица ключей, таймаутов и текущих значений таймера.
* Ключ - хеш от ID модуля, откуда был выполнен вызов, ID модуля вызываемой процедуры обработчика, и имени процедуры обработчика. Идентификаторы модулей можно увидеть, выгрузив конфигурацию в файлы.
* Таймаут - число, рассчитывается в миллисекундах.
* Текущее значение таймера - момент предыдущего срабатывания, дата/время с миллисекундами. Таймеры отталкиваются от текущей даты/времени сеанса в момент компиляции подключения обработчика или реинициализации таблицы.
Эта таблица обслуживается специальным обработчиком, который не является сервисом кластера, а просто часть механизма платформы. Обработчик не учитывает успешность вызова и выполнения вызываемой процедуры.
Эта таблица не относится к сеансовым данным (косвенно упоминается в руководствах лишь как "прочие данные сеанса"), при обращениях к серверу и ряде других операций значения таймеров сбрасываются, и очередной вызов происходит гораздо раньше, чем истёк таймаут.
Реинициализация этой таблицы происходит при любом "возврате на клиент", т.е. при передаче менеджером кластера управления клиенту (штатного, по службе кластера, или по исключению) и передаче хранимых для рабочего процесса сеансовых данных. Штатно - понятно; по службе кластера - имеется в виду служба отладчика, т.е. продолжение действия по прохождении точки останова; по исключению - только если ошибка была восстановимая, касалась сервера либо обмена клиент-сервер и (если запуск был из формы) не касалась блокировок этой формы.
Прекращение обработки конкретной записи этой таблицы происходит, когда из стека исчезает указатель в памяти на область, хранящую тот контекст (форму/модуль и их кэш), откуда выполнялось подключение обработчика (а вовсе не тот контекст, где располагается вызываемая по таймауту процедура, как иногда ошибочно пишут). Грубо говоря для большинства случаев, обработчик стопится, когда закрывается форма или приложение, откуда он стартовал.
Существенно различно в разных релизах до 8.3.11 ведёт себя при остановке на точке останова; в текущих релизах всегда сбрасываются таймауты и сразу стартует обработка заново - и по прохождении останова, и при остановке по ошибке, если ошибка была обработана. Не важно, где находится точка останова - в действиях, вызванных обработчиком, или в других действиях, реинициализация делается всегда.
Поведение аналогично и для файловых, и для клиент-серверных ИБ. Поведение в клиенте тестирования аналогично поведению в обычных запусках клиента. Поведение в веб-клиенте формально одинаковое, но известны случаи, когда в браузере "Safari" таймауты "сжимались" относительно ожидаемого в состоянии "покоя" клиента, т.е. написано было 60, а реально срабатывало через 45-48 секунд.
Сеансы и обработчики. До версии 8.3.7.2008 наличие хотя бы одного сработавшего обработчика ожидания вынуждало сеанс никогда не "засыпать" и даже не считаться пассивным. В некоторых релизах 8.3.9 и 8.3.11 запущенные обработчики не мешали сеансу засыпать и быть впоследствии удалённым, но продолжали работать, что проверено выполнением записи из их процедуры в клиентский файл на локальном ПК (занята ли бывала при этом лицензия, сведений нет) - фиксировать активность сеанса средствами ЖР нельзя было потому, что запись в ЖР это обращение к сервису кластера и вообще к серверу.
Наличие назначенного сеансу соединения никак ни на что не влияло и не влияет. Соединение может пропасть, а обработчик продолжит свою работу.
В настоящее время запущенные обработчики в понятие "активность пользователя" (не юзера-за-экраном, а именно пользователя в админском смысле) не входят. Сведений о том, передаётся ли прежняя сохранённая таблица обработчиков сеансу кластером при возобновлении его работы, или просто реинициализируется, нет.
Из устройства этого механизма следует ряд нюансов.
1. Обработчик можно запускать и останавливать в форме, экземпляр которой создан, но не открыт; в любой момент, пока её контекст есть в некоей переменной. Запускать и останавливать придётся отдельными экспортными процедурами, т.к. обращение "НеоткрытаяФорма.ПодключитьОбработчикОжидания" игнорируется без генерации исключения. С уничтожением переменной формы останавливается и обработчик - поэтому следует быть внимательными, чтобы после закрытия запустившей формы или команды не случилось зависания этой переменной в памяти сеанса.
2. Не-клиентские и не-контекстные процедуры не могут обрабатываться. Логично - в таблице тайминга ориентируемся на хеш, связанный с контекстом. Процедура не должна иметь даже необязательные параметры, и быть экспортной. Также, может быть подключена функция; результат её выполнения игнорируется.
3. В качестве запускаемых обработчиком могут быть процедуры модуля приложения, любого глобального общего модуля, для которого указано исполнение на клиенте (в т.ч. наряду с исполнением на сервере или во внешнем соединении). Если модуль не "чисто" клиентский, по умолчанию директивы компиляции и инструкции препроцессора исполняемой процедуре всё равно не нужны - при наличии флага "Клиент" для модуля обработчик ожидания все его "подходящие" процедуры считает клиентскими. Но, конечно, желательно всё указывать в явном виде. Важно! Запуск и остановка всегда должны находиться в контексте одного модуля, иначе запустить - запустит, но потом не остановит. Это могут быть модуль приложения, глобальные и неглобальные общие модули, модули объектов и модули менеджеров - главное, чтобы вызов старта и остановки происходил в одном модуле.
В модуле приложения подключение можно выполнять в любом системном событии - в ПередНачаломРаботыСистемы оно уже корректно запустится, а в событиях завершения работы системы будет проигнорировано.
4. Если действие на сервере затратило меньше времени, чем таймаут, то обработчик строго по таймауту вызовет нужное, будто серверной приостановки и не было; а если больше, то "собьётся" и вызовется сразу по возвращении с сервера. В старых релизах известны случаи перезапуска не совсем сразу, а через некий некратный таймауту интервал, и лишь потом тайминг восстанавливался; также известны случаи, когда обработчик стартовал даже раньше, чем сбросится на клиент и выведется кэш сообщений пользователю с сервера. Заметим, что в обычных формах в толстом клиенте на последних релизах обработчик иногда продолжает работать независимо от вызова сервера, псевдоасинхронно (впрочем, обычным формам после 8.3.6 вообще стала порой свойственна весьма странная псевдо-асинхронность).
5. Сколько бы раз ни было запущено подключение обработчика некоей процедуры, учитывается лишь последний запуск - он "перебивает" предыдущие. Повторное/многократное отключение обработчика игнорируется без генерации исключения. В том числе и если обработчик вообще не был запущен.
6. Из процедуры, вызванной обработчиком, можно повторно подключать, переподключать с иным таймаутом, останавливать этот обработчик. Например, можно эмулировать однократный запуск - допустим, условие определяется при срабатывании; можно эмулировать многократный запуск-вызов с таймаутом менее 1 секунды. В этом случае, т.е. если внутри процедуры-обработчика однократного таймаута находится повторное её же подключение, получается практически мгновенный и при необходимости бесконечный самовызов. Зависаний и торможений, если в рабочей части вызванного нет "тяжёлых" действий, не замечено.
7. При одинаковом таймауте, обработчики модуля приложения и глобальных модулей более приоритетны при опросе и срабатывании, чем обработчики форм. Между собой обработчики модуля приложения и глобальных модулей "равноправны", формы между собой - тоже. Это означает, что и для однократного, и для постоянного вызова всегда сначала отрабатывает "глобальный", потом "форменный". Независимо от порядка подключения обработчиков, если они были подключены за одну компиляцию фрагмента кода (это хорошо заметно на примере однократных вызовов с таймаутом 0.1). А вот при равных "правах" вызовы отрабатывают по порядку инициализации-подключения их обработчиков.
8. Таймауты, имеющие дробные значения секунд, корректно обрабатываются независимо от значения флага однократности (это легко проверить с помощью ТекущаяУниверсальнаяДатаВМиллисекундах), с точностью до десятых.
9. В синтакс-помощнике указано, что "вызов будет осуществляться только в "состоянии покоя", то есть в тот момент, когда программа не выполняет никаких действий.". Наличие на экране другой формы или модального диалога в общем случае тоже не есть выполнение действия, однако, поведение различно. Обработчик НЕ "тормозят" ни модальные, ни асинхронно-псевдомодальные служебные или платформенные диалоги. Обработчик "тормозят" открытые формы, чей режим открытия окна "Блокировать весь интерфейс". По завершении действий с ними обработка возобновляется, и тайминг не сбивается. Обработчик НЕ тормозят и не сбивают тайминг все остальные разнообразно открытые формы с прочими режимами, даже если форма, где запущен обработчик - их владелец, и для них указано "Блокировать окно владельца".
10. Редко, но используется запуск средствами СОМ полноценного приложения V83.Application. При таком запуске расположенные в модуле приложения обработчики запускаются и живут до конца сеанса, независимо от видимости приложения. Возможен запуск КомОбъект.ПодключитьОбработчикОжидания (справедливо и для модуля приложения, и для форм, хотя в этом случае работа с формами уже совсем фантастика) и остановка аналогично. Важно, что в этом случае при закрытии запускавшего контекста (и формы, и самого запустившего сеанса) запущенный продолжает работать, что при Visible=Ложь кончится снятием через диспетчер задач. В некоторых релизах сеанс, применительно к ком-объекту которого делали вызов, при закрытии приложения выдаёт невосстановимую ошибку.
p.s. Сведения о ёмкости служебной таблицы запущенных обработчиков найти не удалось, т.е. сколько максимум может быть таких обработчиков в сеансе, или в конкретном контексте, данных нет. Эксперимент со 100 разными процедурами с одним или разными таймаутами показал правильную штатную работу.
Я наверняка многое упустил; дополнения и замечания приветствуются.
Использовались релизы 8.3.6.2237, 8.3.18.1289 и 8.3.19.1150
