Re^6: Why they choose to lie about PHP over Perl

Yes I know mod_perl embeds a Perl interpreter in Apache. In much the same way that mod_php does with a PHP interpreter.

However, doing "all sorts of crazy shit to Apache using mod_perl" isn't the same as having the ability to "shutdown, restart and reconfigure Apache from within a Perl script", infact the article you cite doesn't give any of those things as a risk of providing mod_perl in a shared hosting environment.

/J\

Comment on Re^6: Why they choose to lie about PHP over Perl Select or Download Code

Replies are listed 'Best First'.
Re^7: Why they choose to lie about PHP over Perl by diotalevi (Canon) on Aug 02, 2006 at 04:37 UTC
I don't think it's the same. mod_perl really is the same perl process just running different functions for each page. The typical configuration for PHP offers more isolation than mod_perl does under any configuration I'm aware of. We'd have to prevent one mod_perl page from being able to see other mod_perl pages by proxy of the symbol table or other interpreter globals. To do that, we really do need separate processes. I think we solve this by using FastCGI, the same thing that I hear Rails typically runs on. ⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊	[reply]

Replies are listed 'Best First'.

Re^7: Why they choose to lie about PHP over Perl
by diotalevi (Canon) on Aug 02, 2006 at 04:37 UTC

I don't think it's the same. mod_perl really is the same perl process just running different functions for each page. The typical configuration for PHP offers more isolation than mod_perl does under any configuration I'm aware of. We'd have to prevent one mod_perl page from being able to see other mod_perl pages by proxy of the symbol table or other interpreter globals. To do that, we really do need separate processes. I think we solve this by using FastCGI, the same thing that I hear Rails typically runs on.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

[reply]