Creating and destroying hundreds of threads, especially if they are short lived) is (almost) never the right way to do things. This is doubly true for perl's iThreads on win32 which are far heavier that native threads.
Re-jigging your app so that you start a pool of threads and re-use them once they have completed their last task is often quite easy to do.
Take a look at Thread::Queue for a simple mechanism for supplying work to your thread pool. Essentially all that is needed is a wrapper around your blast_thread sub that takes an item of work off of a shared queue and processes it, then loops back and gets another. When the queue is empty, the thread can die. If you need to return values from the threads back to your main process, then a second queue written by the threads and read in a loop by the main process once it has started the thread pool is simple mechanism to put in place.
In reply to Re: A Memory Leak in Perl iThreads?
by BrowserUk
in thread A Memory Leak in Perl iThreads?
by Anonymous Monk
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |