https://www.opennet.me/openforum/vsluhforumID3/46707.html "Five Features Perl 5 Needs Now (http://broadcast.oreilly.com/2008/12/five-features-perl-5-needs-now.html)" - лидер проекта Parrot представил заметку с анализом 5 возможностей, в которых нуждается Perl 5:<br><br><br>- Регулярный выпуск релизов;<br>- Улучшение возможностей в сфере объектно-ориентированного программирования (в качестве примеров приводятся модули Moose (http://search.cpan.org/perldoc?Moose), Mouse (http://search.cpan.org/perldoc?Mouse), autobox (http://search.cpan.org/perldoc?autobox));<br>- Метод разработки расширений на языке Си в стиле Python ctype (http://docs.python.org/library/ctypes.html). Текущая система XS (http://perldoc.perl.org/perlxs.html) излишне усложнена. В качестве прототипа возможного решения приводится модуль P5NCI (http://search.cpan.org/perldoc?P5NCI), позволяющий импортировать функции из любых разделяемых библиотек;<br>- Улучшение интеграции с CPAN, особенно в плане возможности установки модулей для индивидуального использования в ограниченных окружениях ( на...<br><br>URL: http://broadca https://www.opennet.me/openforum/vsluhforumID3/46707.html#16 Wed, 17 Dec 2008 14:14:21 GMT Собсно, сам немного поковырялся и нашел все ответы.<br><br>1. perldoc -q "program shrinks" видимо устарел. Написал тестовую программку, которая успешно освобождала память.<br><br>2. Все "якобы-утечки-памяти" оказались особенностями и оптимизациями, которые просто напросто нужно держать в уме, когда необходимо писать демоны или модули для mod_perl и о которых можно почитать тут<br><br>http://www.opennet.ru/base/dev/perl_memory_leak.txt.html<br>http://www.opennet.ru/base/dev/perl_memory.txt.html <br><br>3. Хотя, хотелось бы видеть в Perl более продвинутые интерфейсы очистки, подобные gc в Python.<br> https://www.opennet.me/openforum/vsluhforumID3/46707.html#15 Wed, 17 Dec 2008 02:52:49 GMT &gt;[оверквотинг удален]<br>&gt;- нормально работало только одно приложение, к которому было первое <br>&gt;обращение клиента. <br>&gt;<br>&gt;Путем научного изыскания нашел, что нужны такие настройки: <br>&gt;PerlOptions +Clone <br>&gt;PerlInterpStart 2 <br>&gt;PerlInterpMax 2 <br>&gt;<br>&gt;Подскажите, что это может быть. <br>&gt;Что делать, если будет 3 и более приложений. <br><br>Увеличить число PerlInterpMax до максимально возможного числа одновременных HTTP-сессий. См. это число в настройках Апача.<br> https://www.opennet.me/openforum/vsluhforumID3/46707.html#14 Wed, 17 Dec 2008 02:37:50 GMT &gt;[оверквотинг удален]<br>&gt; Это неправда уже лет пятнадцать как. Да, когда <br>&gt;в Юниксе память у операционной системы можно было отожрать только одним <br>&gt;способом -- с помощью sbrk(2) -- это было правдой. Но теперь <br>&gt;malloc(3) давно уже не "умный враппер вокруг sbrk(2)". Уже давно требование <br>&gt;непрерывности логического адресного пространства задачи не означает требования непрерывности линейных адресов <br>&gt;ОЗУ, и память операционной системе можно возвращать хоть с конца аллоцированной <br>&gt;области, хоть с начала. <br>&gt;<br>&gt; Perl must die. Пока не научится работать с <br>&gt;ОЗУ по-человечески. А не с помощью "reexec themselves". <br><br>Ты хоть сам читал то, что ты цитируешь? Выделение/освобождение памяти делается функциями malloc/free. Perl их вызывает, как и любая C-шная программа. Нет никакой разницы, что именно стоит за ними. Если free не справляется с освобождением памяти, то почему Perl должен что-то делать сверх этого?<br><br>Если ты видишь воспроизводимую ошибку, напиши багрепорт. Если ты этого не делаешь, то ты и лю https://www.opennet.me/openforum/vsluhforumID3/46707.html#13 Mon, 15 Dec 2008 23:17:06 GMT Претензии он адресовал совершенно правильно. Это ужасная кривость Перловки, которую ее авторы сваливают на операционную систему:<br><br>===<br> How can I free an array or hash so my program shrinks?<br><br> You usually can't. On most operating systems, memory<br> allocated to a program can never be returned to the system.<br> That's why long-running programs sometimes re-exec<br> themselves. Some operating systems (notably, systems that<br> use mmap(2) for allocating large chunks of memory) can<br> reclaim memory that is no longer used, but on such systems,<br> perl must be configured and compiled to use the OS's malloc,<br> not perl's.<br>===<br><br> Это неправда уже лет пятнадцать как. Да, когда в Юниксе память у операционной системы можно было отожрать только одним способом -- с помощью sbrk(2) -- это было правдой. Но теперь malloc(3) давно уже не "умный враппер вокруг sbrk(2)". Уже давно требование непрерывности логического адресного пространства задачи не означает требования непрерывности линейн https://www.opennet.me/openforum/vsluhforumID3/46707.html#12 Mon, 15 Dec 2008 17:45:19 GMT &gt;perldoc не имеет никакого отношения к mod_perl <br><br>...Равно как mod_perl не имеет никакаго отношения к Five Features Perl 5 Needs Now. Тем не менее, вам это не помешало адресовать претензии, касающиеся mod_perl, почему-то непосредственно в адрес perl...<br> https://www.opennet.me/openforum/vsluhforumID3/46707.html#11 Mon, 15 Dec 2008 16:36:48 GMT perldoc не имеет никакого отношения к mod_perl<br> https://www.opennet.me/openforum/vsluhforumID3/46707.html#10 Mon, 15 Dec 2008 13:39:43 GMT &gt;К сожалению, есть такой грешок за Perl... Это можно заметить в mod_perl <br><br>Это грехи mod_perl (и, вероятно, PLPERL), но не самого perl<br> https://www.opennet.me/openforum/vsluhforumID3/46707.html#9 Mon, 15 Dec 2008 13:36:21 GMT &gt;и впредь, умеренней демонстрировать своё невежество :-) <br><br>Улыбнуло :) Особенно после ваших пассажей о красоте Python'а.<br>Не надо переносить недостатки отдельных модулей на всю систему, конкретно - не путайте mod_perl и собственно perl.<br> https://www.opennet.me/openforum/vsluhforumID3/46707.html#8 Mon, 15 Dec 2008 12:32:31 GMT я вам советую почитать документацию на перл<br>perldoc -q "program shrinks"<br>и впредь, умеренней демонстрировать своё невежество :-)<br>