Elizabeth Mattijsen wrote: > >> ... (for modules that don't >> export lots of symbols into the caller's namespace). > > > If you do some memory benchmarks, you'd be surprised to see how much > memory is used by exported symbols. And all of it copied to any thread > that is created. Using significant amounts of CPU and memory. Which > becomes important in many, long running thread situations as mod_perl > with the worker MPM of Apache.
As a mod_perl programmer for a living, I did some benchmarks of these. That's right but I don't really know why it's so memory-consuming. >> Does the module gets unloaded in some way when the thread >> ends ? > > > When a thread starts, a clone of the _entire_ interpreter is made, > including any modules that are loaded. However, any modules that you > load when in the cloned interpreter (thread), are local to that thread > only. The C<useit> merely ensures that the effective C<use> is done at > execution time, rather than at compile time. And if you place a C<useit > Module> inside a thread, then the Module will be C<require>d and its > import executed inside the thread only. And when the thread ends, > everything that was that thread, including the newly loaded module, will > be gone again. Thanks for the explanation (and to Arthur too) >> (BTW your module doesn't provide an interface equivalent to >> use Foo (); >> no Bar (); >> --that doesn't call import().) > > > Indeed. Is there a way to find out whether a subroutine is called > without any parameters or with an empty list? Cause when I can do that, > I can simulate this behaviour as well... Well, "useit Foo" should call import() just like "use Foo" does -- without any arguments. The parser does some magic to distinguish between "use Foo" and "use Foo ()". I think you may provide a useit_noimport() subroutine. But in this case a straight require() is probably simpler.
