vkleЕсли правильно понимаю, нужно каким-то образом очистить память после выхода из экземпляра из уже ненужного инстанса sub client, который стартовал в строке:


Но где и как это сделать правильно? Ну в общем, да. Поубивать все что создано внутри нити и в конце вызвать threads->exit(). Это надо делать конечно же внутри того самого "ненужного инстанса", а не в главном потоке.
Этого должно хватать.

vkleЕще один момент для некоторой оптимизации, как мне кажется, это освобождение неиспользуемых переменных. Подскажите, какими принципами следует руководствоваться для такой вот структуры?Ну так и делать. Все что появляется на куче изнутри нити, должно нитью же и освобождаться.
Еще можно повторно использовать освободившиеся нити. Если клиент ушел - нить помечается как простаивающая и следующий клиент отдается в уже существующую. Но это надо будет переделывать твой проект.

vklePS: По крону перестартовать скрипт - это, конечно, тоже решение. Но не слишком удачное, на мой взгляд. :-)Ну если уж совсем приперло, то...

vkleВ текущем варианте выход из sub client сделан через return 0 . В таком случае после выхода по return 0 в пеерменной $threads[$count] остается ставший ненужным экземпляр "клиента". Но ведь и после threads->exit() в $threads останется индекс уже несуществующего элемента. Его нужно убирать в главном потоке или он сам исчезнет? Вроде сам то не должен исчезнуть...Просто return 0 это нормально. threads->exit() используется для "неожиданного" завершения нити.
И поток это не процесс, он как раз должен исчезать сам. Если ты думаешь о zombie-процессах, то нет, в перловом варианте нитей этого нет.


vkleЕще хочу уточнить, куда помещать threads->exit() - по логике получается что как раз вместо return 0 . Если строкой ранее - то return окажется бесполезен (ошибаюсь?), а если следующей строкой - то завершение работы нити по exit попросту никогда не выполнится. Верно мыслю?Все верно.


vkleПро созданные внутри нити переменные, если можно, несколько слов. Их нужно индивидуально каждую прихлопнуть, или достаточно внутри sub client объявить их как my и они по threads->exit() прекратят свое существование, освободив память?Если это примитивные переменные, то my достаточно. А если это нечто созданное через somemodule->new, то недостаточно.
Си знаешь? Разницу между стековыми переменными и памятью на куче знаешь? Вот это оно и есть. my - стек, new() - куча.


Навскидку, в том огрызке что ты привел, я вижу `$dbh = DBI->connect() / $dbh->disconnect()` этого мало.
На DBI->connect() делается не только коннект к базе, но и инициализация библиотек которые собственно делают коннект. А dbh->disconnect() не обязан эти библиотеки выгружать. А вдруг ты два коннекта открыл к двум разным базам?
Плюс к этому, сами интерфейсные библиотеки могут делать кучу всякого разного, до чего никак не добраться снаружи.
И при всем этом, у DBI нету метода "выгрузить все".

В общем, я в первую очередь убрал бы отсюда всю работу с СУБД. Если я правильно понимаю задачу, то тебе вполне хватит отдавать в клиентскую нить хеш-массив который ты будешь создавать один раз при старте программы. Ну и если нужно, раз в час/сутки/год пусть главный поток отвлекается от ожидания клиентов и перечитывает список переадресации - перестраивает этот хеш-массив.

Если СУБД обязательно нужна внутри нити, то лучше будет вместо DBI использовать что-нибудь другое, более thread-friendly. В идеале вообще, лучше взять оригинальные интерфейсные библиотеки, и сделать свой модуль с оглядкой на их thread-safety как рекомендуют авторы СУБД. Ну или найти соответствующий модуль. Но DBI точно надо убрать нафиг.

vkleЯ думаю, что после завершения нити ссылка на нее (на эту нить) будет храниться в $threads[$count]. В каком месте делать для нее undef - вот что не понятно.Не надо делать, само сделается. Когда нить завершается она автоматом уходит из списка. Конечно если у тебя есть собственная переменная, в которой хранится ссылка на свежезапущенный поток, то надо будет вручную отслеживать когда ее чистить ($thr->is_running() спасет :))
Но список нитей которые ведет сам модуль threads обновляется (и чистится) автоматом.

vkleМожете порекомендовать какое-то thread-friendly решение или модуль?Это не ко мне. Я с MySQL практически не работаю. Но на cpan лежит куча MySQL модулей кроме DBD::MySQL.
Ну и можешь спросить на соответствующем форуме, как можно сделать потоко-безопасное подключение из Си и потом искать соответствующий модуль.