in reply to Re: problem porting to threaded mode
in thread problem porting to threaded mode

Why? Mostly so I can use a lower-cost hosting plan from my IHP, whose plans include a maximum number of processes. When I get it working I mean to run some performance tests between the 'event' version and the 'prefork' version, and decide which to stay with.

Are you sure you mean to say "Thread::Shared"? Its documentation on CPAN includes nothing like the "tie" usage that you recommend. The article by Liz mentions a "proof of concept" module that she wrote called "Thread::Tie" that has such use noted, including {method => ...} as the 3rd operand. But then the Thread::Tie doc says that it should be superceded by an XS/C version for production use.

I'm pretty sure that @dbs has to be shared by some method, so that any thread can untie and retie a hash/db when the db changes, and have this action be effective for all of the threads in the process. I only backed away from having it shared as an experiment/data point.

An alternative that just occurred to me is to create one thread that does all of the DB accesses for the other threads. No sharing needed! Your thoughts (or anyone else's) on this approach? Can I create the thread at post-config time and have it carried over into all the Apache child processes?

If anything, my mod_perl2 code probably contains more locks than necessary at this point. I have gotten several answers from module authors that their modules are thread-safe (or "can't see any reason why not") and have taken locks out accordingly.

Thanks and HNY, cmac