8 Mar
2005
8 Mar
'05
10:22 p.m.
Hartmut Birr wrote:
If a handle
is created, the reference count of an object is dropped to zero. If an
object is dereferenced we must look to the handle and the reference
count.
after an object was created the reference counter should be 1.
dereferencing that object directly after it was created should decrement
it to 0 and delete it. the handle count should match the number of
handles that exist for the object. When creating the first handle the
reference counter should be incremented by 1, when deleting the last
handle to the object it should be decremented by 1. For additional
handles it should remain unchanged. I implemented this behavior in a
local branch that completely replaces the handle implementation using
generic executive handle tables. But i still have to track down a few bugs.
If we increase the reference count at
the first created handle and decrease it on the last deleted handle, it
is not necessary to check the handle count in ObDereferenceObject or
related functions.
As mentioned above I implemented this behavior in my local tree.
They look for
an existing sub key object. If one is found, the parse routine reference
this object and return it. But this is not correct. The parse routine
should only use and reference this existing object, if the reference
count is greater than zero.
This doesn't sound right, the reference count should never be zero
because then the object should be deleted, which means accessing it
would be dangerous. The object in any case needs to be removed from the
list before it gets deleted.
My idea is to split the data for the key object and the
key object
itself. The parsing routine creates the data only once, but it creates
for each request a seperate key object.
I don't really understand the advantage of this. For file systems it's
obvious because these objects represent data streams with different
offsets, ... But i don't really understand how it could be useful for
registry key objects.
Best Regards,
Thomas