Re^2: How to Fix CGI

agreed.

... which takes us back to the problems of using mod_perl in a shared hosting environment - any script can affect the environment of other users, and globals can persist from request to request. I don't know if similar problems exist in PHP.

What would be an ideal starter environment is to be able to:

load Perl at startup
provide completely separate perl environments for different users
load all the required modules at startup
serve each request with a clean "just started" stack, so that previous requests have no impact.

I know very little about the internals, but what about:

starting a single Perl interpreter ("root process")
forking a separate process for each customer / website - this acts as the "parent process" for each website
load required modules into this new "parent process"
for each request, fork a Perl interpreter from the "parent process"

I may be barking up the wrong tree, and I don't know how heavy these forks are (whether they would be a real gain on using straight CGI), but it may be worth a shot.

Clint

Comment on Re^2: How to Fix CGI

Replies are listed 'Best First'.
Re^3: How to Fix CGI by perrin (Chancellor) on Nov 08, 2007 at 14:47 UTC
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.	[reply]
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]


good chemistry is complicated, and a little bit messy -LW
	PerlMonks