Исходное сообщение
"5 возможностей, в которых нуждается Perl 5. 18 декабря Perl5" Отправлено Andrew Kolchoogin, 16-Дек-08 02:17
Претензии он адресовал совершенно правильно. Это ужасная кривость Перловки, которую ее авторы сваливают на операционную систему: ===      How can I free an array or hash so my program shrinks?      You usually can't. On most operating systems, memory      allocated to a program can never be returned to the system.      That's why long-running programs sometimes re-exec      themselves. Some operating systems (notably, systems that      use mmap(2) for allocating large chunks of memory) can      reclaim memory that is no longer used, but on such systems,      perl must be configured and compiled to use the OS's malloc,      not perl's. ===     Это неправда уже лет пятнадцать как. Да, когда в Юниксе память у операционной системы можно было отожрать только одним способом -- с помощью sbrk(2) -- это было правдой. Но теперь malloc(3) давно уже не "умный враппер вокруг sbrk(2)". Уже давно требование непрерывности логического адресного пространства задачи не означает требования непрерывности линейных адресов ОЗУ, и память операционной системе можно возвращать хоть с конца аллоцированной области, хоть с начала.     Perl must die. Пока не научится работать с ОЗУ по-человечески. А не с помощью "reexec themselves".

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Претензии он адресовал совершенно правильно. Это ужасная кривость Перловки, которую ее > авторы сваливают на операционную систему: > === > How can I free an array or > hash so my program shrinks? > You usually can't. On most operating systems, > memory > allocated to a program can never be > returned to the system. > That's why long-running programs sometimes re-exec > themselves. Some operating systems (notably, systems that > use mmap(2) for allocating large chunks of > memory) can > reclaim memory that is no longer used, > but on such systems, > perl must be configured and compiled to > use the OS's malloc, > not perl's. > === > Это неправда уже лет пятнадцать как. Да, когда > в Юниксе память у операционной системы можно было отожрать только одним > способом -- с помощью sbrk(2) -- это было правдой. Но теперь > malloc(3) давно уже не "умный враппер вокруг sbrk(2)". Уже давно требование > непрерывности логического адресного пространства задачи не означает требования непрерывности > линейных адресов ОЗУ, и память операционной системе можно возвращать хоть с > конца аллоцированной области, хоть с начала. > Perl must die. Пока не научится работать с > ОЗУ по-человечески. А не с помощью "reexec themselves".
	Введите код, изображенный на картинке: