До сих пор я узнал, что повлиять на решение mod_perl о выбранном интерпретаторе нелегко. Если кто-то хочет, кажется, что нужно действительно исправить mod_perl на уровне C или предоставить собственный C-обработчик для httpd в качестве ловушки для запуска перед mod_perl. В конце концов, mod_perl - это всего лишь комбинация обработчиков для самого httpd, поэтому можно разместить один перед ним для выполнения некоторых особых действий. Другой вопрос, разумно ли это сделать, потому что придется иметь дело с некоторыми внутренностями mod_perl, такими как тот факт, что в настоящее время нет доступного интерпретатора, и, в конце концов, в моем случае мне понадобится где-то карта для интерпретаторов и связанный с ними каталог для обработки.

В конце концов, это не так просто, и я не хочу патчить mod_perl или начинать с низкого уровня C для обработчика / перехвата httpd.

В целях документации я хочу упомянуть два возможных обходных пути, которые пришли мне в голову:

Пул потоков Perl

Проблема с текущим подходом mod_perl в моем случае заключается в том, что он клонирует интерпретаторы Perl низкого уровня в C, и они запускаются потоками, предоставленными пулом httpd, каждый поток может запускать любой интерпретатор в любой момент времени, если он еще не используется другой поток. При таком подходе кажется невозможным получить доступ к интерпретаторам внутри самого Perl без использования какого-либо низкоуровневого XS, особенно невозможно управлять интерпретаторами и потоками с помощью Perl Threads API просто потому, что это не потоки Perl, это интерпретаторы Perl, выполняемые потоками httpd. В конце концов, оба ведут себя одинаково, потому что во время создания потоков Perl также клонируется текущий интерпретатор и создаются связанные потоки ОС и тому подобное. Но при использовании потоков Perl у вас больше влияния на общие данные и тому подобное.

Таким образом, обходной путь для моей текущей проблемы может заключаться в том, чтобы не позволить mod_perl и его интерпретаторам обрабатывать запрос, а вместо этого создать собственный пул потоков Perl-потоков напрямую при запуске в VHOST с использованием PerlModule или подобное. Этими потоками можно полностью управлять напрямую в Perl, можно создать несколько очередей для диспетчеризации работы в форме абсолютных путей к запрошенным CGI-приложениям и тому подобное. Помимо самого пула потоков потребуется обработчик, который будет вызываться вместо, например, ModPerl :: Registry для работы в качестве диспетчера: ему нужно будет решить на основе некоторых критериев, какой поток использовать, и поместить запрошенный путь в его очередь, а сам поток может в конечном итоге, например, просто создайте новые экземпляры ModPerl :: Registry для обработки данного файла. Конечно, кое-где понадобится клей ...

Конечно, у этого подхода есть некоторые недостатки: он звучит как изрядный объем работы, удваивает некоторые функции, уже реализованные mod_perl, особенно в отношении обслуживания пула, и удваивает количество используемых потоков и памяти, потому что интерпретаторы и потоки mod_perl будут только использоваться для выполнения обработчика диспетчера, и, кроме того, у вас будут потоки и интерпретаторы для обработки запросов в потоках Perl. Количество потоков не должно быть большой проблемой, так как один из mod_perl просто спит и будет ждать, пока поток Perl завершит свою работу.

@ INC-Hook с изменениями исходного кода

Другой, и я полагаю, более простой подход - использовать @INC-хуки для Perl-кода require снова в комбинации с собственным обработчиком mod_perl, расширяющим ModPerl :: Registry. Ключевым моментом является то, что обработчик - это первое место, где читается запрошенный файл, и его источник может быть изменен перед его компиляцией. Каждый

use XY::Z;
XY::Z->new(...);

можно изменить на

use SomePrefix::XY::Z;
SomePrefix::XY::Z->new(...);

где SomePrefix - это просто полный путь к родительскому каталогу запрошенного файла, измененный на действительный Perl название пакета. ModPerl :: Registry уже делает нечто подобное при преобразовании запрошенный сценарий CGI автоматически в обработчик mod_perl, так что это работает в целом, и ModPerl :: Registry уже предоставляет некоторую логику для генерации имени пакета и тому подобного. Это изменение приводит к тому, что Perl больше не будет находить пакеты автоматически, просто потому, что они не существуют с новым именем в месте, известном Perl, где применяется ловушка @INC.

Хук отвечает за распознавание таких измененных пакетов просто из-за имени SomePrefix или префикса маркера перед SomePrefix или чего-то еще, и сопоставляет их с файлом в файловой системе, чтобы предоставить дескриптор запрошенного файла, который Perl может загрузить во время «требуется». Кроме того, ловушка будет обеспечивать обратный вызов, который вызывается Perl для каждой строки прочитанного файла и будет функционировать как фильтр исходного кода, снова изменяя каждый оператор «package», «use» или «require» так, чтобы SomePrefix был перед . Это снова приведет к тому, что ловушка будет отвечать за предоставление дескрипторов файлов для этих пакетов и т. Д.

Ключевым моментом здесь является изменение исходного кода один раз во время выполнения: вместо «XY / Z.pm», который обычно требуется Perl, он будет доступен n раз в моей структуре каталогов и будет сохранен как «XY / Z.pm» в % INC позволяет Perl требовать "SomePrefix / XY / Z.pm", который будет храниться в% INC и уникален для каждого интерпретатора Perl, используемого mod_perl, поскольку SomePrefix отражает уникальный установочный каталог запрошенного файла. Perl больше не может думать, что он уже загрузил XY :: Z только потому, что раньше он обрабатывал запрос из другого каталога.

Конечно, это работает только для простого "использования ...;" операторы, такие как "eval (" require $ package ");" немного усложнит ситуацию.

Комментарии приветствуются ... :-)

PerlOptions - это переменная с областью действия DIR, не ограниченная VirtualHosts, поэтому новые пулы интерпретаторов могут быть созданы для любого местоположения. Эти директивы могут быть даже помещены в файлы .htaccess для простоты настройки, но что-то вроде этого в вашем httpd.conf должно дать вам желаемый эффект:

<Location /cgi-bin/software1/customer1>
   PerlOptions +Parent
</Location>
<Location /cgi-bin/software1/customer2>
   PerlOptions +Parent
</Location>
<Location /cgi-bin/software2/customer1>
   PerlOptions +Parent
</Location>
<Location /cgi-bin/software2/customer2>
   PerlOptions +Parent
</Location>