The problem with join is that there is no equivalent to the WNOHANG parameter of waitpid, so you cannot join threads as they terminate. Rather, you have to join them in some order and if the first thread handle you attempt to join is the last to finish, all the others remain consuming process resources until it terminates.

For start-run-die-start another style algorithms, as are common with forking servers, it makes it difficult to control resource consumption by limiting the number of concurrent threads to some fixed maximum by only starting the next thread when one terminates. That's why I tend to detach the threads and use a shared var to track how many are still running, but if you need to retrieve their return values, you're stuck.

That said, Perl's threads are sufficiently heavyweight that using a long running pool of looping threads that take new work items from a queue is generally a better option anyway, but the absence of a non-blocking join is a pain for some things.

As stated above, thread memory is returned to the process when the thread terminates, not the OS. The memory becomes a part of the free memory pool(s) that new program elements, both code and data will be allocated from as needed.

What that means, is that if any of your existing threads allocate scalars, or arrays or instantiate new instance of classes etc. etc., then the memory from terminated threads is recycled to provide it. If you start a new thread, then that memory will be used to provide for that new thread.

At the very extreme, if your threaded perl process terminated threads and never needed to allocate another bean of memory, and other processes on your system continued to call for more and more memory until the only "free memory" in the system was that freed from the terminated threads within your process, then the OS would swap that free memory to disk, and the other process would be allocated what it needed.

That called swapping--and everyone knows swapping is bad right?-- but the clever bit is that if your process never attempts to re-use that swapped out free (virtual) memory, then it will just stay on disk and so it's equivalent of real memory will be available to any and every other process in the system anyway. Swapping is only bad if it happens to memory that is in constant use and results in thrashing.

So, what is the "memory issue" you have with Perl's threads?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

The issue was my application, before I reworte it, was chewing up about 80% of a gig of DDR memory. It is an app that connects to over 500 servers and for each server the app creates 1 thread and three socket connections (1 to the server and 2 to MySQL database). Each thread also creates pretty extensive hash tables (sometimes well over a few thousand keys). I am aware of perl's hash table memory hogging but the constant-time O(1) lookup is needed for speed of execution.

I also run a front end for this app via a webpage that I host on my apache web server on the same machine so I was worried about the resources left over to handle any http queries. In the end I rewrote the app to implement some load balancing and had the app respawn itself after ((scalar(@servers)/5)+1) and then start from where it left off. At first I tried system() but this of course did not work due to the blocking nature of system wating for a return so I used exec() to overwrite the current pid and dump the resources back to the OS. Seems to be working out nicely and each iteration only uses about 20% of the memory now.


www.perlskripts.com