Problem with ksycoca on windows

[Ralf Habacker]

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 
CreateFileMapping()/OpenFileMapping().

> 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 
disconnected.
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 
signal.

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 ?

Ralf