2009-08-05 2 views
4

У меня довольно интенсивный сервер сокетов чата, написанный на Twisted Python, я запускаю его с помощью internet.TCPServer с фабрикой и фабричными ссылками на объект протокола, который обрабатывает все связь с клиентом.В Twisted Python. Убедитесь, что экземпляр протокола полностью освобожден.

Как я могу убедиться, что экземпляр протокола полностью уничтожает себя после отключения клиента?

У меня есть функция с именем connectionLost, которая запускается, как только клиент отключается, и я пытаюсь остановить все действия прямо там, но я подозреваю, что некоторые элементы реактора (например, экземпляры twisted.words) продолжают работать для устаревших экземпляров протокола.

Что было бы лучшим подходом к решению этого вопроса?

Спасибо!

+0

Я хотел бы ответить на этот вопрос, но для этого требуется некоторое разъяснение. Нет такой вещи, как «экземпляр twisted.words», с одной стороны - «twisted.words» - это пакет, а не класс. Какой конкретный случай, по-вашему, по-прежнему существует? Какое конкретное поведение вы видите, что заставляет вас поверить, что ваши экземпляры протокола слишком долго поддерживаются? Вы видите сообщения журнала или сетевой трафик или измененное состояние на других объектах или что? Проще говоря, вы не можете заставить объект быть освобожденным в Python, вам нужно просто удалить все ссылки на него. – Glyph

+0

Спасибо. Я сделаю все возможное, чтобы описать то, что я испытывал в то время, но детали могут быть неточными, поскольку я больше не использую эту службу сокетов. Каждое новое подключение к сокету TCP запустило экземпляр XMPPClientFactory (twisted.words.protocols.jabber.client.XMPPClientFactory), который управлял соединением с jabber-сервером, я ожидал, что экземпляр протокола будет освобожден и будет уничтожен связанный объект клиента после того, как TCP клиент отключается, в то время как на самом деле казалось, что объекты клиента jabber не были уничтожены. Пожалуйста, дайте мне знать, если это лучше описывает проблему. Благодаря! –

ответ

-1

ok, для сортировки этой проблемы. Я установил метод __del__ в классе протокола, и теперь я регистрирую экземпляры протокола, которые не были собраны в течение 1 минуты с момента отсоединения клиента.

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

Спасибо!

+0

Метод '__del__' - очень плохая идея. Это предотвратит сбор циклов. См. . – Glyph

Смежные вопросы