> On Tue, Dec 6, 2011 at 5:35 AM, Desilets, Alain
> <alain.desil...@nrc-cnrc.gc.ca> wrote:
>> 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.
If you're running on a unix environment, you probably want to run
multi-process, not multithreaded. Most modules that work in CGI will
work here, but you need to be aware of issues with opening files and
sockets before the parent process forks. This is described in detail
in the docs. Is there a specific module that you need that isn't
working for you?
>> 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.
Well, there's no real distinction between "globals" and "package
variables" in perl. I think that by globals you mean package
variables that are in the current package so they can be referenced
without a package prefix.
Package variables are indeed persistent in mod_perl and similar web
environments. You should only use them for things that you want to
persist between requests. Everything else goes in lexically-scoped
("my") variables.
- Perrin
