Hi,
I've looked a little bit more in the registry and object manager problem. I think we have a little bug in the object manager and a huge bug in the registry code. I start with the object manager. 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. At the moment this is not an atomic operation. It is not easy to make it to an atomic operation. 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. The registry problem is a little bit more difficult. If we look for a registry key, the parse function is used. 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. But the status of this object isn't clear. 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. This is like a file systems, which use many file objects but only one fcb for an on disk file. Any ideas or suggestions?
- Hartmut
Hartmut Birr schrieb:
Mike Nordell schrieb:
I think we might be barking up the wrong tree here, working around a problem in the registry code (?) by adding bloat and slowing-down code to one of the central code "services".
It isn't a problem of the registry. It is a design problem of the object manger for all objects which have a Close and/or Delete function. There is always a gap between dropping the reference or handle count and calling the Close or Delete function.
- Hartmut
Ros-dev mailing list Ros-dev@reactos.com http://reactos.com:8080/mailman/listinfo/ros-dev