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