Всем привет.

Очень большой проект, с кучей юнитов и компонентов. Думаю по этому глупо приводить здесь код.
На формах и фреймах лежат созданные в дизайнере TTimer. Фреймы создаются "вручную" и добавляются на форму в единичном экземпляре. Сооствественно объекты TTimer тоже создаются не в множественном числе, без create/free. Всего таймеров в проекте 18.
И вот меняя все лишь порядок создания фреймов вываливается исключение 'not enough timers available'. происходит это при попытке включения таймера:



Кто-нибудь знает причину, почему такое это может происходить и вообще как это можно побороть, кроме замены таймеров на tthread?

Fr0sT-Brutal,

авторЯ бы поставил логирующий брякпоинт на создание таймера и проверил, что код вызывается в самом деле 18 раз, а не 1800

там на разных фреймах это все и показывает, что по разу создается фрейм и так же поразу идет активация. Просто как назло вносил изменения без внесения в CSV и теперь придется откатыватся на большой кусок, но желательно было бы разобратьсяв причинах.


Bred eFeMsvd, ты часы на руке носишь? больше одной штуки? или как?
я вообще не ношу, я счастливый.

Fr0sT-Brutal,

А что там можно проверить?

Тут в одном описании попалась попытка, разъясняющая ситуацию. У парнишки было около 400 таймеров на различных формах и ошибка тоже случалась при включении. Объясняли это тем, что в очереди текущего окна уже есть сообшеня WM_TIMER и ощибка просодит во время TTimer.Update(). В процедуре ничего нет особо криминиального, что можно из дельфи проковырять: обращение к Windows.SetTimer(). попробовал перед вызовом сделать Application.ProcessMessages, но это не помогает.

приложение Win64, handles = 16289. Это x3FA. Вроде не должно быть ограничений на хэндлы. Или я что то не знаю?

Большое спасибо за предупреждение по поводу хэндлов. Можно ли проблему ограничения количества решить перенесением части графических форм и фреймов в динамическую библиотеку?

нашел в реджистри два ключа:

USERProcessHandleQuota и GDIProcessHandleQuota .

Знает кто-нибудь про это, будет ли решением проблемы?

white_nigger...хотя бы динамическое создание и освобождение используемых ресурсов.

чесно говоря, я постоянно задаю этот вопрос. Но шеф утверждает, что обязательное требование.

YuRockНет, решением проблемы будет только нахождение утечки хэндлов.

да, после перезагрузки с таймером это проблему не решило. Остается только жесткое порно в виде поиска кривизны.

Aleksandr Sharahov,

таймеры используются для разных целей. Один все время контролирует протокол выполнения и ошибок и записывет даннве в файл. Другой, например, контролирует в ните ручного сканера наличие новых данных и вытягивет их оттуда. Причем в зависимости от фрейма обработка этих данных идет поразному - в одном случае это могут быть данные товара, в другом места или какого либо бокса со вспомогательным кодом. Причем с таким механизмом, имея один скэнер и одну нить по его обработке, данные скэнера можно использовать даже между разными программами.
Третий контролирует состояние двери у робота и синхронизирует эти данные между парой других программ.
и т.д. по поводу специфических таймеров.
Но есть и довольно тупые задачи для таймеров: например при запросе какого либо поиска данных или просто фетчинг этих данных, запрос выполняется в отдельной нити, а данные из нити вытягиваются по таймеру в компоненты типа AdvSmoothListBox, или раз в секунду обновляет данные со значением из базы для таких компонентов. Такие можно как раз озадачиться и объединить в один.

За 8 лет разработки именно этой части кода, просто так такую проблему не решить - очень сильные изменения придется вносить в фремворк. А потом еще непонятно сколько тестировать под разными конфигурациями у клиентов - у одних один набор фич отображается, у других другое.

YuRockЗапусти ты уже, наконец-то, в каком-нибудь профайлере свою прогу и закрой через время - он покажет, какие ресурсы не удалены.

Регклярно так и делаю. Потому как часто коллеги, как пионэры, забывают финализировать объекты.

Но в этом случае fastmm не сообщает ничего полезного.

Dimitry SibiryakovНа это всё достаточно одного таймера, который по истечению заданного периода
запускает ту или иную функцию.

Не всегда. И не везде. Есть задачи, которые очень критичны ко времени обработки. И если в такой ситуации таймер с интервалом 800мс проводит обработку свое функции 1.5 сек. - это ненормально.

Да и никто не отменял ситуацию, когда что-нибудь неправильно пошло, один конкретный таймер остановился, но остальные работают дальше. Простой оборудованя - это для нас потеря денег. Если таймер отвечающий за передачу сообщений от внешней системы остановился, то оператор может найти нужное лекарство через нашу программу (за обновление на экране отвечает другой таймер). То есть отказ одного таймера не есть крах работы всей системы.

YuRockОн же показывал, что >16к хэндлов в списке процессов отображается. Там тихий ужас какой-то.

Правильно заметил - в тасклисте не только таймеры отображаются, а все хэндлы, используемые приложением.
Но почему именно этот конкретный таймер чудит - сегодня буду разбираться. Причем в правиле фреймворка стоит, что при деактивации фрейма, таймера и вспомогательный трэд останавливаются, а при активации запускаются заново. И именно этот таймер при новом запуске бросает тоже самое исключение, а вот на других фреймах, где подобная реализация, такого не происходит.