Re^3: How to Fix CGI

What you describe above is already possible with mod_perl. Just set MaxRequestsPerChild to 1, and each process will exit after a single request and cause another one to be forked.

It's better than CGI, but it still sucks compared to really using mod_perl. It means you can't have persistent database connections, cached database statement handles or data, and similar performance tweaks that are only possible in a persistent environment.

Comment on Re^3: How to Fix CGI

Replies are listed 'Best First'.
Re^4: How to Fix CGI by markjugg (Curate) on Dec 02, 2008 at 03:04 UTC
If this works reasonably well, why hasn't it caught on? Mark Stosberg	[reply]
Re^5: How to Fix CGI by perrin (Chancellor) on Dec 02, 2008 at 03:20 UTC
I don't think ISPs are very interested in solving this problem, and the solution I described isn't what people expect from either mod_perl or CGI, so it would be hard to market. I do use this when doing development on mod_perl modules. If you avoid loading the module you're working on before forking, you can test it without ever doing restarts this way, and it works for mod_perl-specific modules that can't be run under CGI.	[reply]
Re^4: How to Fix CGI by Anonymous Monk on Nov 29, 2007 at 11:21 UTC
ISP and shared webhosts cannot provide mod_perl simply because: with mod_perl, users can do deadly things by specifying Perl* directives in their own .htaccess files. There is currently no way to forbid this. There is in mod_ruby. Patch for this has been submitted (maybe more than once), but rejected. I don't think mod_perl developers care enough about shared hosting environments.	[reply]
Re^5: How to Fix CGI by perrin (Chancellor) on Nov 29, 2007 at 15:21 UTC
That's absurd. First, there is nothing that can be done via .htaccess directives that's any worse than code you can write in mod_ruby or mod_php. Second, there has never been a patch like you describe submitted to the mod_perl dev list. I've been on it for years.	[reply]
Re^5: How to Fix CGI by arkturuz (Curate) on Nov 29, 2007 at 16:19 UTC
So, why not write a mod_perl module that will do just that (restrict user powers)? ISPs could then configure their servers to force using mod_perl powers via this module only. Users gain speed, performance, DB persistance, etc; ISPs gain control. I'm still learning mod_perl, but from what I read, I think something like this is very possible. Most of the users don't need the full mod_perl horse power, just a small, but still significant, subset. Module like this could enable it, I believe, exporting some API and handlers users should then use instead of default ones, and controling that default stuff doesn't get called.	[reply]