On Tue, Dec 6, 2011 at 3:11 PM, Desilets, Alain <alain.desil...@nrc-cnrc.gc.ca> wrote: > 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.
I wouldn't expect that. In a multi-process situation, files and sockets are not shared unless you opened them before forking. DBI is a classic example of something that works fine in multi-process situations but may fail in multithreaded ones. > The one module that I know for sure does not work in a forked or > multi-threaded environment is KinoSearch. I don't use KinoSearch so I don't know why it doesn't work, but I'd suggest that when something seems to be not working it's worth checking with the developer or mailing list for the module and checking on this list if anyone is using it. > Not sure what you mean by "lexically scoped". You probably know all about them but haven't heard that term before. Try http://perl.plover.com/FAQs/Namespaces.html for some explanations and terminology. > 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. That's true! I assume you mean this: my $foo = 7; sub print_foo { print $foo; } That's called a closure. Don't do that unless you want persistence. Using locally declared variables in subs and passing in arguments instead of grabbing data directly from variables in a larger scope is good programming practice, and it's the way to avoid unwanted variable persistence in mod_perl and FastCGI. - Perrin
