in reply to A Memory Leak in Perl iThreads?

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.


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail

Replies are listed 'Best First'.
Re: Re: A Memory Leak in Perl iThreads?
by Anonymous Monk on Mar 21, 2004 at 19:28 UTC
    Ok.. I just found out a work around here, but I would like to inform you of another new discovery I have just made. OPENDIR is not thread safe... I have a sub :
    #sub get_files { # # my ($work_dir, $ext) = @_; # opendir (FILES, "$work_dir"); # my @to_go = grep {/\.$ext$/} readdir(FILES); # close(FILES); # return (@to_go); # #}
    and I cant use it any more in my threaded program in windows, or else I get a Windows error!!!, this sub is not used by threads, but any way, its fatal... there goes another great perl bug to submit!

    Best wishes,
    Paulo C.

    P.S.I already did a workaround in the sub using @files = <*>;