Problem with ksycoca on windows
ralf.habacker at freenet.de
Fri Feb 15 13:46:43 GMT 2008
David Faure schrieb:
> On Friday 15 February 2008, Ralf Habacker wrote:
>>> We can also dump our mmap code since QFile has mmap support now in 4.4.
>> You are refering to QSharedMemory class or something else ?
> No he's talking about the current solution for ksycoca: a file that is mmap'ed by all processes,
> so that they don't have to load the complete file upfront (like you want to do on Windows :).
> But I don't think it will help with the problem of replacing the file while it's being used (on Windows),
> so it's a bit orthogonal to this discussion.
> I'm fine with the patch being committed with a TODO for now (and an explanation in the code, too;
> the problem is not that windows doesn't support mmap in itself,
not under this function name but with
> but that we can't replace the file while the app is using it).
Closing the file after mapping make it free for renaming (see other
mail), but using the FileMapping functions results in other problems
which needs to be solved. It is possible to give a FileMapping a global
name, but this implies to have a strategy for updating the database
because the readonly mapped area is only closed when all clients are
This means an outdated file mapping has to be still in memory until all
clients are disconnected. This implies that the global name of this
mapping is blocked until all clients are disconnected.
An updated file mapping must then use then a different name. Christian
suggested to spread this new name with the KSycoca's databasechanged
This raises the question how new clients could know the currently used
mapping name, maybe as Christian suggested by using a mutex on windows.
Would using QSharedMemory raises similar problems ?
More information about the kde-core-devel