(cc'ing mod_perl list) On Tue, Dec 6, 2011 at 5:35 AM, Desilets, Alain <alain.desil...@nrc-cnrc.gc.ca> wrote: > Thx to Fred, Andre and Jon for answering. BTW: I hope I didn't offend anyone. > What I really meant was:
No offense taken at all. Welcome to mod_perl! > > "Is it me or is mod_perl *much more slippery than standard CGI*?" > > I know that there are lots of folks out there using mod_perl, so I assume it > can be used in a safe way. I am just trying to figure out where the slippery > patches are, and how easy it will be to slip on them for me, my team, my > external collaborators, and even writers of CPAN modules. > > The last point is important. Fred wrote: > > " Most developers find it useful to use CPAN modules which are generally high > quality." > > That's what I do also. In fact, I don't think I have ever used a third party > module that wasn't from CPAN, and they are, as you say, generally high > quality. > > However, even those high quality CPAN modules can fall flat on their face > when they are used in contexts that they weren't designed for. For example, I > recently discovered that several CPAN modules cannot be used safely in a > multithreaded or forked environment. Some of them fail "nicely" (i.e. they > KNOW they aren't supposed to be used in this kind of environment and tell you > at run time), but others just crash the process upon spawning a new fork or > thread, and leave you with no indication as to what caused this. I am > concerned that similar issues might arise when using certain CPAN modules in > a mod_perl context. > > --- > Question: Is this something that has been known to happen (CPAN modules that > don't work well in mod_perl), and if so, how common is it? > --- > > Coming back to where the slippery patches are. Initially, it looked to me > that the main thing to watch out for was global variables. By this, I mean > variables that can be seen from anywhere in the code. I was OK with that, > because I never use global variables, and I have taught everyone in my team > to stay away from them. Also, I don't see global variables being used in CPAN > modules. > > But after doing a couple experiments, I now realize that package variables > are also unsafe in a mod_perl environment. Although I try to avoid them, I > don't consider package variables to be "sloppy". Even though they are public > and can be seen outside of the package, they can only be seen by those files > which actually load the package. So, I am a bit more uncomfortable with that > particular slippery patch, because I know that I and some of my team members > use package variables occasionally. I also see lots of CPAN modules that use > them as well. > > One thing that I think will greatly mitigate the risk for us is that we use > Test Driven Development, and have PerlUnit tests for every class in our > application. This forces us to write our classes that don't assume they will > be used in a single CGI script call context. That's because the tests > process instantiated and uses a the class several times in a number of tests > and scenarios. But I think this will only help to a point. It's one thing to > have a process that runs dozens of tests on a class, but it's a completely > different thing to have a process which uses that class to execute thousands > of requests per day, and which stays up and running for months at a time. > > I guess the only way to find out whether mod_perl works for us is to try it, > while keeping the door for going back to standard CGI in case our app is too > brittle for it. > > Time to buy a mod_perl cookbook I guess ;-). > > Again, thx for your useful answers. > > Alain > > -----Original Message----- > From: Fred Moyer [mailto:f...@redhotpenguin.com] > Sent: Monday, December 05, 2011 4:45 PM > To: Desilets, Alain > Cc: mod_perl list > Subject: Re: Is it me or is mod_perl extremely dangerous? > > On Mon, Dec 5, 2011 at 1:06 PM, Desilets, Alain > <alain.desil...@nrc-cnrc.gc.ca> wrote: >> I'm a complete newbie to mod_perl, and after reading the following >> documentation: >> >> http://perl.apache.org/docs/1.0/guide/porting.html >> >> I am scared witless by the fact that many variables don't get reinitialized >> between calls to the CGI scripts. >> >> Particularly scary is the example provided on that page, where the >> authentication status is stored in a global variable that doesn't get >> reinitialized. In that example, if Joe logs into the system, and Jane then >> runs the script, she can get access to the system also without every logging >> in, because Joe's authentication status is still there. YIKES! > > If you read through the entire example, you will see the point of the > example is to show what can happen from bad programming. > > "Because of sloppy programming, a global variable was not reset at the > beginning of the program and voila, you can easily peek into someone > else's email! Here is an example of sloppy code" > >> But I'm not convinced, because package variables are not reinitialized >> either! > > "The solution is trivial--reset $authenticated to 0 at the beginning > of the program." > >> But... we don't have control over how third party modules were implemented, >> and we use A LOT OF THEM. So I am still very concerned about that, because >> we could end up using a third party module that makes use of package >> variables in a way that is not mod_perl friendly. > > You're always free to write your own modules which you have complete > control over. Most developers find it useful to use CPAN modules > which are generally high quality. > > >> Am I being too conservative here, or am I right to be that nervous? > > I do not think you are justified in stating that mod_perl is > 'extremely dangerous'. > > >> What precautions can we take to prevent this sort of thing from happening? > > If you are just starting out with mod_perl, I would skip over the > porting documentation and go straight to the mod_perl2 specific > documentation. I would also suggest reviewing the following links for > mod_perl development best practices > > http://perl.apache.org > > http://www.modperlcookbook.org/ > > http://modperlbook.org/
