I came across this trying to track down a bug in a linux program where
two separate instances of TRegistry were being used to both read and
write data to the registry. Depending on the order in which operations
were done, writes were being lost and not turning up in the XML file.
The outcome is even more unpredictable when the TRegistry instances are
owned by multiple threads.
Digging deeper, the problem seems to be that:
a) Each TRegistry instance creates its own TXMLRegistry object.
b) When the TXMLRegistry is created, it loads the XML File into memory.
c) Where a key is closed, the cached data is written back (flushed), but
never refreshed.
The result is that with each TRegistry instance caching its own copy,
every time a key is closed, the updates from the other instances are
overwritten.
This seems to be a bug to me as there is nothing to say that you should
only have one TRegistry instance at any one time.
The obvious fix seems to be for there to be a single instance of
TXMLRegistry shared between all instances of TRegistry - or at least one
TXMLRegistry for use when GlobalXMLFile is true and another for when
GlobalXMLFile is false.
Is there a good reason not to propose this as a bug fix?
Tony Whyman
MWA
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
