in reply to Re^4: forks.pm, CGI::App,TT and DBD::mysql
in thread forks.pm, CGI::App,TT and DBD::mysql

Okay. Your trying to use a forked open from within a simulated thread, in conjuction with CGI, MySQL and run under the auspices of Apache?

My first reaction is: ambitious!

My second reaction is threads are much improved of late. If you are having specific problems with memory consumption and/or processor usage, work on those. There are techniques that can reduce both with careful programming.

General advice includes:

  1. Don't try to use objects across threads.

    (The same applies to forks I think?).

  2. Load as little as possile prior to spawning your threads. Require what you need inside the thread rather than using it at the top of the main program. Thread::Use is a handy tool for this.
  3. Don't spawn threads, use them once and throw them away. Start a pool of threads and then re-use them.

    It's a different philosophy from the forking model, but if you want the benefits of threads, you have to play to their strengths not their (or their implementations), weaknesses.

My 3rd reaction is that maybe liz will browse by over the weekend and put her finger on the forks/fork issue. I cannot help with that as forks doesn't (and probably couldn't) run where I live.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
  • Comment on Re^5: forks.pm, CGI::App,TT and DBD::mysql