Jeff L wrote:
Robert Shearman wrote:
Jeff L wrote:
It seems that this would not be a unique problem in wine, is there a standard way to handle memory tracking so that if memory is freed, at a later time we can check to see if the pointer is still valid?
It sounds like you could benefit from using the handle table functions in ntdll.
Looks promising. There don't appear to be examples of how to use the functions. I assume that I declare memory to be of type RTL_HANDLE_TABLE and call RtlInitializeHandleTable to initialise it. Then there is a call to RtlpAllocateSomeHandles to get the space for the handles. After this RtlAllocateHandle gets a handle off the free list and RtlFreeHandle to release the handle.
How do you access the memory pointed to by the handle? I was thinking that I would need to stash the address I am managing into the handle. It looks like I can do that with the RTL_HANDLE pointer retuned by RtlAllocateHandle but from then on it does not look like I can get the address of the handle as RtlIsValidHandle etc do not return it.
Yes, it does. You can look at dlls/ntdll/tests/rtl.c to see how the functions can be used.
If I run out of handles, how do I reallocate the table or add to it?
You can't. It is intended to be a fixed size table.
Are the functions thread safe if I anchor the handletable off a static variable in the dll? I am going to need a persistent table for the life of the dll. Hence it has the potential to be used by multiple threads.
No. You need to protect the accessing of the handle table and handles with a critical section.