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

This works just fine as soon as I comment out forks.

Then leave use forks; commented out. Problem solved.

That may sound like sarcasm, but it's also good advice. You do not need forks.pm in order to use fork or the forking open.

Read the documentation on forks and you'll discover that it is a way of emulating the threads api. for those situations where threads are (or were) unreliable.

For what you are doing in this snippet, you do not need and should not be using forks.

So stop forking around and stop trying to use the module for things that it was not intended for :)

You might also try reading http://perlmonks.com/index.pl?node=Writeup%20Formatting%20Tips

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^3: forks.pm, CGI::App,TT and DBD::mysql Download Code

Replies are listed 'Best First'.
Re^4: forks.pm, CGI::App,TT and DBD::mysql by perldragon80 (Sexton) on Jul 31, 2004 at 04:06 UTC
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. :)	[reply]
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]