8 Mar
2005
8 Mar
'05
9:55 p.m.
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(a)reactos.com
http://reactos.com:8080/mailman/listinfo/ros-dev