(cc'ing the mod_perl list on this one also, please remember to reply all :)
On Tue, Dec 6, 2011 at 11:28 AM, Dr James A Smith <j...@sanger.ac.uk> wrote: > On 06/12/2011 19:09, Fred Moyer wrote: >> (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. > > Perl::Critic is your friend in number of places - there are some subtle > gotchas that people don't realise that are more subtle than the ones > you mentioned - and perlcritic will point a lot of these out.... > > In a mod_perl registry script, what is wrong with the following: > > my $user = $self->user_from_cookie( $user_cookie ) if $user_cookie; > > ?
