parser

Написать ответ на текущее сообщение

 

 
   команды управления поиском

Ответ

Misha v.3 10.04.2013 17:12

У меня были подозрения, что файл, подключаемый через use, может нарушить работу текущего скрипта, т.к. его методы и переменные переопределят уже существующие.
может.
но ничего не мешает не просто переименовать @main[] в @run[], а добавить в начале @CLASS. и использовать его статически.
в этом случае точно не будет никаких перекрытий методов/переменных.
Также есть проблема с обработкой большого объема данных в течение длительного времени.
запуская из одного скрипта другой вы только усугубляете ситуацию, увеличивая и время выполнения и потребление памяти. если установлено ограничение на время процесса, то первый процесс будет убит, а с ним умрёт и дочерний.
а вот с помощью редиректа вы можете обойти проблему.
в любом случае, прежде чем что-то делать, надо понять -- а есть-ли эта проблема?
судя по вашим формулировкам вы в этом не уверены.

также можно пооптимизировать алгоритм. например, у меня в одном из проектов при загрузке проверяются 180+ тысяч ячеек таблицы с помощью regex/hash lookup-ов. и ничего, даже на древнем тормозном сервере вписываюсь в 1 минуту включая загрузку проверенного в БД, а на нормальном сервере процесс занимает буквально десяток секунд.
Если это делать в одном скрипте, то процесс в какой-то момент зависает, дальше ничего не обрабатывается.
не верю.
то, что кто-то прибил процесс -- верю. а что процесс завис -- нет.
Если сделать через use или file::load, то все будет обрабатываться в одном процессе, что приведет к тому же зависанию, поэтому и стал пробовать через file::cgi/exec.
именно. и не будет дополнительных save/load файла. не будет кода, который должен подчищать ненужные больше файлы. сам код упростится.

в любом случае сделать так, чтобы file::cgi/exec заработали -- несложно (я указал направление, в каком надо копать), но это тупиковая ветка. если у вас есть проблема с тем, что всё выполняется долго и вы не вписываетесь в лимиты -- вы не решите её таким образом.