in reply to Re^8: memory leaks with threads (race of 1)
in thread memory leaks with threads
I've seen that if one has a single core, then one can avoid many race conditions because only one thread ever runs at a time.
I completely agree that moving from single-cpu multi-threading to multi-cpu multi-threading often causes latent bugs to become glaringly obvious. Though I think this is more apparent with compiled-to-native code than ithreads, simply because you do not get the 'atomicity' of native machine instructions with Perl op-codes.
The basis of my gut feel is the lack of any great program level memory allocations, and the inherent simplicity of the OPs demo code.
Given the latest info from the OP, that creating & destroying threads consisting soley of sub{ 1; } causes fast, massive leaks on his system, I have to suspect that the leak is inherent in the implementation of the creation and freeing of interpreter structures on his platform.
The big difference between *nix and Win32 in this regard is that Win32 returns memory segments allocated by the creation of threads to the OS. So, even if during the creation of the internal structures required to create a new interpreter, there is some circular reference or other reference counting error, that on the *nix system means that some part of it does not get free'd back to the memory pool for re-use, on the win32 system, the entire kit'n'kaboodle gets given back to the OS, so reference counting errors do not persist.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^10: memory leaks with threads (race of 1)
by misc (Friar) on Jul 10, 2007 at 12:21 UTC |