Re: Re: Re: Re: Re: mod_perl and shared environments don't mix - do they?

[perrin]

It's true, Apache::Resource would allow malicious users to remove limits. It is meant to help people keep from shooting themselves in the foot, not to prevent intentional attacks. It might work better to set rlimits as root during apache startup.

it made sense to me since you can load C binaries in a Perl module

The extensions to PHP that allow things like database access are also written in C. As I understand it, writing custom PHP libraries that use C code is a very popular practice among high-volume sites.

the php code tends to be written precisely to the purpose at hand, and may easily be half as complex, giving it a speed advantage

Coding yourself vs. using a CPAN module is only faster if you can always write faster code than the people who write the modules. Given the high-quality of the most common Perl modules (DBI for example), this seems unlikely. There certainly are some large "kitchen-sink" CPAN modules out there, but anyone who is concerned about performance can easilly steer clear of them.

I don't think that mod_perl's API for accessing apache data is inherently more dangerous than the PHP equivalent. They both give you access to the same information about the request. What is more dangerous is that mod_perl doesn't provide a safe sandbox where code written by one user can't possibly affect code written by another. This is addressed in mod_perl 2, but it's not stable yet. Meanwhile, people looking for shared hosting with mod_perl still need to go with a virtual server or SpeedyCGI.