Using the standard threads distributed with Perl 5.8.x:

1. If you use the module in your main thread before spawning threads A & B, threads A & B will be able to use the module.
2. Or, if you require the module in thread A and then spawn thread B from within thread A, the module will be available to thread B.
3. If you spawn thread A from the main thread, require the module within thread A and then later spawn thread B from the main thread, thread B would have to also require the module before using it.

Someone (I think renodino), has mentioned that he has (or is working on) a module that allows you to share objects across threads. I am unsure of the details of how this works or if it requires require in all sharing threads. Doing a supersearch for "shared objects" may turn up the appropriate threads and further information.

Be wary of using any modules in the Thread::* namespace. Some (like Thread::Queue) are just fine in conjunction with threads. Some others are remnents from perl5005 threads and do not work with threads. Still others attempted to bridge the transition from 5005threads to ithreads in the early days of ithreads and never quite got finished.

Unfortunately, there is no way apart from trial and error to work out which modules fall into which category. I sorely wish that the entire Thread::* namespace would be dropped or deprecated and any ithreads-capable modules would be moved into the threads;:* namespace--but I doubt it will ever happen.

Someone (I think renodino), has mentioned that he has (or is working on) a module that allows you to share objects across threads.

Yes. See Thread::Apartment. I have successfully used it for a number of projects, including HTTP::Daemon::Threaded, and Tk::Threaded (tho the latter has some issues w/ tie()'d variables that keep me from CPANing it yet). I've also used the same general concepts for DBIx::Threaded, tho it needs to be updated to migrate to Thread::Apartment...or actually, a variant of Thread::Apartment I hope to build atop Thread::Sociable once its completed.

Caveat: This isn't truly "sharing", but rather "proxying", ala Microsoft's COM model.

1. - Do you really need to delay requiring the module? Could you pull it in the main thread before starting the child threads?
2. - If its a runtime issue, can all child threads do the same discover-which-module process?
3. - If its expensive to discover the module, then perhaps you could have one thread find the module name and then stash that in a shared scalar. The other threads could do their own require from that.

Basically, I am writing a RPC like server, it listen on IO::Socket, and then spawn new threads for each request.

1. The client then need to ``register'' itself on the server first, which a thread A on server should ``require'' the module.

2. The client then use the returned stub to call a method (through AUTOLOAD). A nother thread B on server should then make the actuall call.

Currently I can only put ``require'' and actual call both in thread B to load the module and let the symbol available.

What I tent to is load it once at thread A, so following methods calls won't repeately load it again.

I have also come up with an idea that by keeping my own shared HASH symbol table at the main thread, and use AUTOLOAD to point it when necessary. But will it achieveable? or would it make performance better? I don't know.

Thanks

Ah I get it. You're letting the threads die after handling a request and starting a new thread per request.

If you're concerned about performance, the general advice is to have a persistent thread pool, with the number of threads proportional to the number of execution cores on your system.

There appears to be a CPAN module, Thread::Pool which automates this process. If you did this, then you'll just require the modules in-thread and they'll only be loaded once per thread. Looking at the docs, you'll want max == min so that threads don't die off.

There are performance tradeoffs here. Using a pool should reduce mean latency (since you don't have to start a new perl thread before handling the request) but may introduce unpredictably to the latency, since the pool may be at max when a new request comes in. An appropriately-sized pool should increase the throughput (ops/second) since less work is being done per op (you aren't starting a whole new thread).