On 17/02/2015 04:01, Lorenzo Trivelli wrote:
While analyzing a resource exaustion problem on a production machine, (Windows) I found out astrange behaviour of boost::threads regarding event object. The problem is that after a certain number of iterations it semms that the thread lib allocates an EventHandle which is never freed. I managed to reproduce in some ways the behaviour, but I'm a bit clueless about its reason.
Typically the way things work is that as long as a lock (or whatever it is you're using -- you didn't actually say) goes uncontended, or minimally contended such that a spin resolves it, then it will allocate no kernel handles. A kernel handle is only required when the lock is contended for sufficiently long that it needs to put the thread to sleep. This handle should be released when the lock itself is deleted. If the lock is itself global or otherwise held by a global object, or if it's in an object that you are memory-leaking, then it won't go away until you close the process.
3) if you want I can attach the sample code with a but if info on how to reproduce the behaviour
Without knowing at least *which* threading object you're using, I doubt a report will get anywhere.