On December 6, 2004 09:24 pm, Aaron Gray wrote:
Either disallow two uses of the same image or provide a second changes file.
Perhaps another option would be for the VM process to create a second small "lock file" whenever the changes file is open for write, and remove it when it's closed or the process exits. On startup, VM would check if the lock file exists, if it does, will not start. Of course there is the problem of crashes ..
There is no way to guarentee integerity of a shared changes/image file using locking. You would need some form of notification and reloading as well, either that or a shared memory mapped file. All too dangerous considering crashes and incompatible changes and more crashes, and lost work, and annoyance at machines behaviour for loosing work...
Isn't the current situation exactly that, by proceses potentially sharing (and corrupting) the same changes file? I was trying to describe a simple mechanism that would move that danger from the changes file to a small lock file, are you saying it would be even worse?
How to distinguish a "crash that did not remove the lock" from "another process is already running". This could be done by the VM writing, on a separate thread, a new "DateStamp" every 5 seconds inside the lock file and closing it quickly.
When a "VM process" starts and the "lock file" exists, it would: - read the lock file contents several times for > 5 seconds (20 to be safe) - if the lock file content never changed, we had a crash, we remove lock and start - else there must be another process running.
Would something like that work and be implemented ..
Not really.
Aaron