Re^2: FastCGi on IIS... The tale of Microsoft and my new Perl Module...

[cosmicperl]

This module is designed to be a drop in replacement for using CGI, you are getting some benefits of FastCGI, reusing processes rather than making new ones, and the perl interpreter is already loaded.

Any Perl CGI script should be able to use this module, without any specific FastCGI coding or adjustments. Of course scripts coded in FastCGI will work as normal without this module.

Lyle

[perrin]

Any Perl CGI script should be able to use this module, without any specific FastCGI coding or adjustments.

I can tell you right away that it won't work perfectly. What you're doing is mostly the same as what Apache::Registry does. If someone defines a global, it will still be there the next time the script is run. If they load a module, it will still be there, and it will not reload even if they change the module. There's a lot of mod_perl documentation discussing these issues and how to cope with them.

[cosmicperl]

I'm working on cleanup routines now and trying to contain what each script loads. Any help is much appreciated :)

Update:- namespace::clean does a lot of what's needed...

[perrin]

I'm afraid namespace::clean will only help with things in the current package. It won't help with reloading modules when they change. For mod_perl, we use Apache2::Reload to do that, and I think there are similar things for FastCGI.

The fact is though, all of this is a total hack. There is no way to reload modules built into perl, and none of the approaches people have tried to add on actually work for all cases. So, the best advice is to code differently for persistent environments like FastCGI and mod_perl.

I would advise you to offer an option that works more like the other FastCGI modules and like mod_perl handlers, i.e. it doesn't try to pretend to be CGI, so it offers the full speed advantage of a persistent interpreter. If you don't do that, your solution will always be significantly slower than mod_perl and PHP over FastCGI.