> > On Tue, Dec 6, 2011 at 5:35 AM, Desilets, Alain
> > <[email protected]> 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?
I'm using Windows. In my experience, modules that don't work well with
multithread, also don't work well with fork, and vice-versa.
The one module that I know for sure does not work in a forked or multi-threaded
environment is KinoSearch. Because of that, we had to move to the Lucy module
instead.
Last summer, I had also concluded (possibly falsely) that there were other
modules in my application which were not thread-safe. But I could not identify
which ones, because when I ran the app in multi-thread fashion, all I got was a
one line error message about not being able to free address such and such. I
assumed that this was due to some perl module that was accessing an external
DLL, but I can't be sure. I had googled the error message, and I seem to recall
that it had been linked to problems with non-thread safe modules. Can't
remember the details.
> 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.
Not sure what you mean by "lexically scoped".
But declaring a variable as "my" is not sufficient to prevent it from being
persistent. You can declare a package variable with "my" and it will persist.
Alain
