Доброго времени суток!

Досталась мне в наследство UDF, написанная на free pascal с поддержкой потоков и потоковых переменных (threadvar).
Реализовано примерно так, как описано тут: https://www.ibphoenix.com/resources/documents/how_to/doc_307 (в секции Thread-level initialization and finalization).

И обнаружил странную для меня вещь - после использования какой-нибудь функции из этой библиотеки при закрытии коннекта (в архитектуре supeserver) процедура DllEntry не вызывается с reason = DLL_THREAD_DETACH.
Но при этом она вызывается именно с такой причиной самопроизвольно спустя примерно минуту-полторы после того как заканчивается активность в этом коннекте (хотя еще даже транзакция, в которой был вызов UDF не закоммичена).
Ясень пень, что это делает сервер FB (кому ж еще?)
Пробовал на FB 2.5., FB 3.0.2, на классике и суперсервере (все - под Windows) - поведение одинаковое

В связи с этим вопрос - потоки в UDF когда порождаются и убиваются сервером?

Вопрос интересен и в теории, но и на практике тоже.
В этой библиотеке отдельными функциями создаются в памяти объекты (как threadvar), отдельными функциями как-то обрабатываются и уничтожаются.
Полагаю, что её создатели считали, что в суперсервере будет в dll по одному потоку на коннект, но это очевидно не так.
Пока активность в коннекте непрерывна, то все хорошо (потому видимо и работало и никто этого не замечал). Но если создать объект, что-то поделать на клиенте больше пары минут без участия сервера и обратиться к этому объекту снова - то его уже не будет, так как поток, в котором он создавался уже завершен сервером, а новое обращение будет уже в новом потоке.

Не исключаю, что несу бред, но другого объяснения тому, что я наблюдаю, я не нахожу...

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

Заранее благодарю за помощь!

Спасибо за ответы.
Буду думать, чего теперь с этим делать...

Привет! В SM это и уже хз кто так написал. Но самое удивительное, что оно работает, видимо потому что всегда это быстро проходит без простоев, потому и проскакивает все в одном потоке.
Все отчеты так работают в SM - работа со списками практически во всех есть. Но там вся работа в рамках одного запроса (хранимки) - создали, наполнили, отработали, убили.

Я бы этого даже не заметил, но сейчас переделываю их под linux, и вот с этим сборщиком мусора трахаюсь, так как в linux нет DllEntry и не понятно, когда чистить эти threadvars, если их принудительно не почистили

Оно почти так и сделано - есть функции создания, всяких там манипуляций и удаления, но только через threadvars, а они в каждом потоке свои. Теперь по-хорошему надо свой пул писать и самому им управлять, а не на потоки ориентироваться.