I called TlsFree after storing something in the Thread Local Storage and when I call TlsGetValue(...) it returns the object! Why is this?
Printable View
I called TlsFree after storing something in the Thread Local Storage and when I call TlsGetValue(...) it returns the object! Why is this?
Deallocating a resource doesn't necessarily destroy the "bits" of that resource. So it still might appear to be there, even though it isn't. Accessing it is still wrong.
As an analogy, imagine that you've been banned from campus. That doesn't mean you can't go on campus, it just means you'll get in trouble if you get caught :)
The real question of the day is why are you trying to use a freed buffer? Or were you just curious.
It *is* freed. The values of the bits are still there, however. If you want, you could clear the buffer to zero (or some other value indicating "been freed"), BEFORE freeing it.
Accessing freed storage is a common error, which often goes undetected for exactly this reason. Some runtimes will mark storage with special byte values before freeing it, when operating in debug mode, to try to catch these errors.
As explained above, the free function doesn't actually remove the data in the entry, it just says "this index can be used again".
Something like this seems like a good idea:
--Code:void myTlsFree(long &index)
{
TlsSetValue(index, 0);
TlsFree(index);
index = 0;
}
Mats
There were many programs that broke on the transition to Win95 because it was far less forgiving about accessing freed memory than Win 3.x.