Re^4: forks.pm, CGI::App,TT and DBD::mysql

Thanks for your response.
I didn't make myself as clear as I should have. In my original post I meant I was using threads (but didn't want to because of their unreliability and processor + memory intensive consumption).

I then realized I might be able to use forks.pm and not have to change any of my threads code (plus I thought it might even be faster due to the speed of the system fork in linux). When I tried this is when I ran into several problems, one of which was the filehandle error. I slimmed it all down to one little script just to show that there was an issue with the forks.pm module and opening filehandles.

Thanks for all the help already given and for any future advice, about perl as well as site etiquette. :)

Comment on Re^4: forks.pm, CGI::App,TT and DBD::mysql

Replies are listed 'Best First'.
Re^5: forks.pm, CGI::App,TT and DBD::mysql by BrowserUk (Patriarch) on Jul 31, 2004 at 05:06 UTC
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: Don't try to use objects across threads. (The same applies to forks I think?). 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. 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	[reply]

Replies are listed 'Best First'.

Re^5: forks.pm, CGI::App,TT and DBD::mysql
by BrowserUk (Patriarch) on Jul 31, 2004 at 05:06 UTC

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:

Don't try to use objects across threads.
(The same applies to forks I think?).
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.
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

[reply]