That said, I'd suggest you revisit your architecture. Obviously, there are many pieces I'm not privy to, but your current code is very non-deterministic, and I'd consider it a bit dangerous to put into production. Have you considered combining the Parse and Process inside individual threads, with a lock around the output file, and creating a fixed size pool of threads executing the resulting method ? You'd have to pass the new sockets to the threads as fileno's and reconstitute them via fdopen(), but that's still likely to be faster than constantly spawning/destroying new threads, and certainly more manageable/debuggable. It may not solve your immediate issue, but I suspect you'll find the cause faster.
Interestingly, a recent use.perl.org journal pointed to some related threads links, esp. the unfortunately titled 'The Problem With Threads'. In brief, nondeterminism is bad, and in your case, possibly unsafe.
One more suggestion: try monitoring with Devel::STrace. I used it to diagnose a similar problem with a highly threaded app...turned out to be some unexpected behavior when the socket peer dropped the connection unexpectedly. (However, its also likely sensitive to your transient thread architecture).
One last hint: assuming you use a newer version of threads, you may want to adjust the thread stacksize (depending on the platform) to help reduce footprint.
In reply to Re: CPU Leaking Threads
by renodino
in thread CPU Leaking Threads
by Trizor
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |