At 10:55 AM 7/24/02 -0700, Marc M. Adkins wrote: > > etc.... It wouldn't save much, but every little bit helps, > > specifically in > > a mod_perl environment... >This seems to imply that every existing module should have modifications >made to make it "well behaved" in a threaded environment.
No, they're usually well-behaved in a threaded environment. I'm talking about optimizations here, things that will make it better suited for a mod_perl environment with long running processes and memory usage issues... >Question: does :unique imply :shared so that these changes require variable >locking? The way I understand it, is that: unique implies "shared, read only after cloning". >... In which case modules should _not_ have these changes made? Oh, >wait, does unique even do anything if use threads; hasn't been invoked? It only has meaning in a threaded environment, i.e. a Perl built with thread support, a "use threads" and with threads, other than the main thread, actually running. >This is really off the wall...but if Perl has a "constant" mechanism (and it >probably does somewhere I don't know about ;) then it might make sense for >all constants to automagically be unique. I don't know too much of the innards, but it appears to me that the "unique" mechanism was developed for exactly that purpose, and then later given another API with the ": unique" attribute. (Arthur, please correct me if I'm talking nonsense here... ;-) Liz
