ru.perl

 
 - RU.PERL ----------------------------------------------------------------------
 From : Mike Shoyher                         2:5020/52      26 Jun 2000  18:47:13
 To : Eugene B. Berdnikov
 Subject : Re: [p]thread
 -------------------------------------------------------------------------------- 
 

 >  Hу вот и договорились. Hе зачастую, а *редко* 
 
 Это замечательно, что после пересказа тривиальщины про работу fork в юникс
 и непонятных рассказов про какую-то компиляцию перловых модулей все-таки
 пришли к мысли что байткод и данные хранятся вместе и перемешаны. Причем,
 не неким мифическим способом что "последние две страницы", а так как
 выйдет.
 
 Пойдем дальше.
  
 
 >  (это постараться надо,
 >  чтобы так написать скрипт - сначала use один модуль, поработали,
 >  потом use другой, еще поработали, потом опять use/eval? Ох...:).
 >  Более того, чтобы так не происходило, Perl имеет специальные
 >  механизмы (все "use" рекурсивно компилируются _до_ исполнения скрипта,
 >  если не считать BEGIN).
 
 Есть еще require, Autoloader (знакомо, надеюсь?), да и eval опять же 
 
 > И байткоды, к Вашему сведению, практически
 >  никогда не меняются, за исключением тех, которые генерятся по new
 >  + regexp'ы без /о. Hо если кто-то забывает писать /о - это проблемы
 >  его головы.
 
 /o имеет смысл только при наличии в pattern переменных, если их там нет -
 он не действует. А Вам никогда не приходилось делать regexp с переменной 
 и без /o? Если переменная изменяется и матчить нужно именно ее текущее
 значение? Причем тут голова-то вообще?  
 
 >  Короче, все ясно. Ваши аргументы сводятся к убеждению, что область,
 >  занятая байткодом, постоянно перепахивается перлом. Мои - к тому,
 >  что этого добиться _очень_ трудно, надо специально постараться.
 >  Дискутировать больше вроде не о чем.
 
 А теперь я Вам, наверное, страшную тайну открою. Аллокатор памяти в перле
 не последовательный, а пуловый. То есть всю память он разбивает на пулы
 chunk-ов разных размеров и при выделении памяти выдает кусок не
 последовательно за последним выданным, а наиболее подходящиий по размеру из
 оставшихся в пулах. О чем можно прочесть хотя бы в perlguts. Так что все
 Ваши рассуждения лишаются смысла.
 
 Mike Shoyher
 --- Gnus v5.6.45/XEmacs 21.1 - "Canyonlands"
  * Origin: E-Labs (2:5020/52.0)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор