Сохраняйте Perl XSUB SharedObject загруженным в mod_perl - PullRequest
Новая
       29

Сохраняйте Perl XSUB SharedObject загруженным в mod_perl

1 голос
/ 11 ноября 2011

Я написал оболочку Perl XSUB для очень простого C API (для которого у меня нет источника).

C API состоит из 4 функций.Одна из которых возвращает «дескриптор» (просто целое число), и это значение должно быть передано обратно любой из трех других функций, чтобы получить нужный внутренний «объект» для вызова.Предполагается, что C API хранит список этих объектов и выдает правильный для поставляемого дескриптора.

При запуске в автономном скрипте все прекрасно работает.

Я сейчас пытаюсь запустить этот API под apache2 с mod_perl.Вначале все работает нормально - я возвращаю «дескриптор» обратно клиенту, а затем клиент делает последующие вызовы с тем же значением дескриптора.Но после (очень короткого) периода бездействия C API решает, что он потерял свои списки «объектов» и начинает заново.

Я предполагаю, что это потому, что основной файл .so выгружается.

Итак, мой вопрос:

Могу ли я что-нибудь сделать, чтобы предотвратить выгрузку Apache / Perl этого .SO?Единственное, что, похоже, работает - это запуск apache в режиме отладки с -X.

Спасибо

Ответы [ 2 ]

2 голосов
/ 11 ноября 2011

Я предполагаю, что это потому, что основной файл .so выгружается.

Нет, это потому, что другой дочерний элемент apache получает HTTP-запрос и ничего не знаето других детях

Основные детали http://perl.apache.org/docs/1.0/guide/porting.html

0 голосов
/ 10 февраля 2012

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

Может помочь при настройке параметров MPM.

Согласно документации MPM, вы можете избежать прерывания и перезапуска дочерних процессов, установив соответствующие директивы.

В дополнение к набору активных дочерних процессов могут существовать дополнительные дочерние процессы, которые завершаются, но по крайней мере один серверный поток все еще обрабатывает существующее клиентское соединение. Могут присутствовать процессы завершения MaxClients, хотя можно ожидать, что фактическое число будет намного меньше. Этого поведения можно избежать, отключив завершение отдельных дочерних процессов, что достигается следующим образом:

  • установить значение MaxRequestsPerChild на ноль

  • установить значение MaxSpareThreads равным значению MaxClients

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

...