|P is for Practical|
Re^3: ithreads memory leakby BrowserUk (Pope)
|on Apr 09, 2015 at 17:41 UTC||Need Help??|
First:Ignore anything and everything sundialsvc4 says. He has a proven track record of meaningless, misdirected & pure malicious posts on subjects he has provably no knowledge or understanding of. And in particular, threads.
then kill the walking timer,
The fundamental problem with your code is this:
Run that code and watch the process (top or whatever). It immediately creates a thread that just sleeps for a thousand seconds. The main thread then waits for 5 seconds and then (attempts to) kills the sleeping thread. But the thread never sees the "signal" ... until it finishes sleeping.
This is because those "signals" aren't real signals; but some home-brewed simulation of them that cannot even interrupt a sleep. They (the pseudo-signals), should never have been added to the threads api; and they should never be used!
And that explains the "memory growth" problem; you are expecting these threads to go away when before you start their replacements; but they simply won't.
And that's a problem for your architecture which is built around that premise.
I have 3 solutions for you: one is a quick fix; and the other two will required fairly extensive changes to your program.
(But its my dinner time right now, so I'll detail them in a while. I just wanted to warn you to ignore sundialsvc4 who has never posted a single line of working code here. Be warned!)
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked