![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Сброс таблицы дескрипторов
StanislavB © (2003-07-19 08:32:00)
Есть проблема для систем реального времени. По некоторым причинам растет таблица дескрипторов, что очевидно видно в TaskMenager. При переполнении таблицы приложения и операционная система начинают глючить. Необходимо перезагружать все. Знает ли кто нибудь из мастеров способ очистки таблицы из проги от неиспользованных, и некорректно освобожденных дескрипторов. Заранее благодарен.
StanislavB (2003-07-31 23:14:00) [1]
Спасибо, нашел. Только что это за проекты ".ohp"?
AlexKniga (2003-07-31 13:42:00) [2]
StanislavB
> oh.exe не могу найти.
%Delphi%\Bin\OH.EXE
StanislavB (2003-07-30 22:39:00) [3]
"ты делаешь Socket.Close в обработчике OnError ?"
Кажется делал. Точно не помню, но кажется нарывался на исключение. Попробую еще, имеет смысл. Сейчас не могу, надо ехать на объект в командировку. Если это то, что нужно, то я должник.
oh.exe не могу найти. Это интересно и для других целей. Например закрывать не нужные процессы.
mzu (2003-07-30 11:43:00) [4]
проверь при помощи oh.exe - какие дескрипторы не закрыты. В соответствии с этим и действовать
Polevi (2003-07-30 09:36:00) [5]
продолжай в том же духе, пусть плодятся и множаться дескприпторы !
StanislavB (2003-07-29 22:03:00) [6]
Нет.
Polevi (2003-07-29 10:12:00) [7]
2StanislavB (29.07.03 08:41)
ты исходный код TClientSocket смотрел ?
ты делаешь Socket.Close в обработчике OnError ?
StanislavB (2003-07-29 08:41:00) [8]
В том то и дело, что я "на элементарном уровне" отслеживаю отсутствие "сервера", а не "клиента", мне в этом помогает компонент ClientSocket, но делать Disconnect не имеет смысла, так как Connecta то и не было. И освобождать ресурсы то же нечего. Открытого сокета не было. Очевидно, TCP/IP пытается найти серверный сокет и где то бродит, занимая дескриптор для не открытого сокета. Возможно так. Очевидно как то можно остановить этот процесс и осводить дескриптор. Тайм аут не помогает. Или я действительно ничего не понимаю. Завал.
Morfein (2003-07-28 22:29:00) [9]
Ну так а что же ты тогда на "кривую систему" валишь, рассказываешь нам про какие-то переполненные таблицы дескрипторов, если ты на элементарном уровне не можешь отследить отсутствие клиента и освободить ресурсы?
Под кривым дескриптром я понимаю дескриптор, который никаким образом не связан с реальными ресурсами.
StanislavB (2003-07-28 22:11:00) [10]
Для Polevi. Освобождать handle какого объекта? Я не встречал в литературе ни намека на необходимость этого действия, считая, что компонент сам делает все необходимое. Мною делались подобные попытки, но они ни к чему не приводили.
Polevi (2003-07-28 11:58:00) [11]
неправильно обрабатываешь disconnect, там нужно освобождать handle
StanislavB (2003-07-28 08:39:00) [12]
Я не понял, что такое кривой дескриптор. Я их не создаю. Например. Поставил компонент ClientSocket и делаю коннект по необходимому порту и хосту. Все в порядке. идет обмен информацией. Нет проблем. Таблица дескрипторов не растет. Но в конце рабочего дня. Клиент, который находится в другом конце города, выключил компьютер. Сокет периодически пытается наладить коннект и генерит сообщение об ошибке коннекта. Когда утром включается удаленный узел, сокет радостно сообщает об этом факте и передает этому узлу информацию. А за это время таблица дескрипторов увеличилась на несколько сотен или тысяч. Это один из примеров. Сейчас я делаю систему на основе WebAplication. Там начинаю сталкиваться с похожей проблемой. Системы должны работать круглосуточно и без перезагрузок многие месяцы, пока не получается.
Morfein (2003-07-27 18:50:00) [13]
>> Но бывают ситуации, когда CloseHandle не приводит к желаемому результату, и дескриптор не освобождается. Это особенно характерно для сетевых интерфейсов.
Это бывает только в том случае, если ему передают кривой дескриптор. А для сетевых интерфейсов существуют хорошие функции shutdown() и CloseSocket()
panov (2003-07-27 15:21:00) [14]
>StanislavB (26.07.03 20:12)
Увеличение количества дескрипторов - однозначно в ошибке в программе.
Недавно боролся с такой же проблемой при программировании сокетов в Socket API.
Дай более подробную информацию о коде...
StanislavB (2003-07-26 20:12:00) [15]
Спасибо, коллеги. Очевидно проблема не рразрешимая. Я очень внимательно слежу за освобождением памяти и дескрипторов. Но бывают ситуации, когда CloseHandle не приводит к желаемому результату, и дескриптор не освобождается. Это особенно характерно для сетевых интерфейсов. Еще раз спасибо, буду дальше искать выход, возможно не стандартный.
Polevi (2003-07-25 09:51:00) [16]
если не было вызова CloseHandle кто знает что дескриптор "неиспользуется" ??? на основании чего какаято ф-ия или утилита может сделать такой вывод ?
StanislavB (2003-07-25 09:16:00) [17]
Для уточнения. На "системе реального времени" крутится не одна прога, а система прог, вызываемых в решение автоматически, обменивающихся информацией между собой через зашаренную память.
Действительно, под дескрипторами имеею в виду handles.
mzu (2003-07-21 09:57:00) [18]
Кстати, для уточнения. Под дескрипторами уважаемый StanislavB имеет в виду handles?
mzu (2003-07-21 09:56:00) [19]
Можеть быть вопрос в стиле программирования: типа жизнь всех дескрипторов должна быть однозначно привязана к жизни объектов. Или к количеству instances этого объекта (Не знаю как по-русски сказать, извините).
А если не переписывать программу заново, то в MS Windows Resource Kit есть замечательная программулинка (oh.exe) которая
позволяет видеть список открытых дескрипторов любого процесса с указанием на что они ссылаются. Может это поможет найти место, где дескриптор создаётся и не удаляется.
ValeraVV (2003-07-21 07:40:00) [20]
На этой "системе реального времени" обычно крутится постоянно одна прога - скорее всего написанная StanislavB, так нельзя ли проверить как эта прога освобождает дескрипторы