in reply to Share symbol table between threads

I don't know how to mark the symbol table as shared, so...
  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.
I'd love to know more about the circumstances in which you want to do this.

Replies are listed 'Best First'.
Re^2: Share symbol table between threads
by jwu (Novice) on Oct 04, 2006 at 11:23 UTC
    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

[reply]
      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).

[reply]
        Thanks jbert,

        I will keep that in mind, but for now, I will choose the simple solution by ``require'' it every time.

        The principle of this module is to be simple. The whole module only in 200 lines (thanks for AUTOLOAD). I probably use Thread::Pool as a plugin later.

        By the way, the module will be on CPAN as RPC::Object (wait some time before it appears). Thanks for your help.

[reply]

In Section Seekers of Perl Wisdom