in reply to Re^2: using many threads and conserving stack size
in thread using many threads and conserving stack size

What that comes down to getting the parent to know when a thread has finished.

You could use Thread::Queue, and each thread can enqueue its id when it's finished. The parent could wait on that queue or poll it.

Or you could poll threads->list(threads::joinable) for threads you can polish off by joining. You might do that before creating a new thread, I suppose.

Replies are listed 'Best First'.
Re^4: using many threads and conserving stack size
by danmcb (Monk) on Nov 12, 2008 at 16:04 UTC

    thanks. seems a bit odd, I don't see why it has to work like this. It ought to be trivial to run the script until all threads are ended, without clogging memory

    In the end I just made a threadless version with a very simple scheduler, it took me about an hour to change it and it works perfectly on almost 0 resources

[reply]

      I believe what's going on here is that each thread, once it has finished, has a "return" value in its hot little hands.

      If you detach the thread, you've said you don't want the "return" value, so as soon as it's finished, the thread can tidy up after itself and leave the building.

      Otherwise, until you join (or detach) the thread, it's sitting there, waiting patiently to give its final report, before it tidies up and leaves. (Kind of sad, really, given how much you care !)

[reply]

        yes, that makes sense. Awwww, now I have thread-guilt!

        What doesn't make sense is that if you detach a thread, it gets stomped on when the main thread ends. AFAIK there is no way to say "I don't care what value it returns, but I DO want it to actually get there".

        Guess I just want it all ...

[reply]

In Section Seekers of Perl Wisdom