[ros-dev] Registry and ObjectManager (was FreeLdr Part II)

Hartmut Birr hartmut.birr at gmx.de
Wed Mar 9 00:10:37 CET 2005


Thomas Weidenmueller schrieb:

>
>> 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.
>
This doesn't sound right, but the current implemention of key objects
uses this way.

>> 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.
>
I see two ways to solve the wrong referencing problem. The first one is,
we create the key object and reference it again. One reference is for
holding the key object in the parent key structure valid. The second
reference is for the caller (ObFindObject..) and he could do what he
want with it. The problem is, the first reference is never removed and
it is not possible to dereference (delete) the parent. The other way is
a special data structur between the parent key and the child keys. This
structure has an internal reference count, which is incremented when a
child key is created and decremented when a key is deleted. The create
or delete operation occurs only if the hive is looked. The creating or
deleting of this data structur has nothing to do with the real reference
count of the object. It is always triggered by the create (parse) or
delete operation.

- Hartmut




More information about the Ros-dev mailing list