This means that I have to rework all main classes to achieve POSIX persistence semantics in Windows even when a process crashes. This will require using memory mapped files to emulate shared memory (with some tricks to avoid performance problems with file-memory synchronization if it's possible). I think that this approach will be much more portable than the Shmem approach.
Well that move makes worries me. The use I currently put shmem/interprocess to is for high-speed IPC communications. Could you explain what the potential performance impact is with this change.
This means that the OS will synchronize file and memory contents from time to time, since shared memory will be implemented with memory mapped files. However, I will create those files emulating shared memory with the FILE_ATTRIBUTE_TEMPORARY attribute, that according to MSDN: "A file is being used for temporary storage. File systems avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data. Otherwise, the data is written after the handle is closed." I think that with this attribute the overhead will be minimal. I've just got write access to CVS so I will upload Interprocess so that you can test if the performance is enough. Regards, Ion