Milan,

Sorry, I misunderstood your post.

After re-reading your suggestion, I think that it is simple enough
that you could give it a try yourself without even touching the VM :)

You could set up a "background process" in Squeak to handle your
lock file (see method #forkAt:, and you could set up a check for
the lock file when the Squeak restarts (see #startUp:resuming:).

Dave

On Tue, Dec 07, 2004 at 08:15:21AM -0500, Milan Zimmermann wrote:
> On December 7, 2004 06:15 am, David T. Lewis wrote:
> > On Mon, Dec 06, 2004 at 07:21:20PM -0500, Milan Zimmermann wrote:
> > > On December 6, 2004 03:48 pm, Tim Rowledge wrote:
> > > > "Aaron Gray" <angray at beeb.net> wrote:
> <snip>
> >
> > Actually, file locking can be done directly if you want to (for example, if
> > you have loaded the OSProcess package, see UnixOSProcessAccessor>>lockFile:
> > and friends).
> >
> > But stop for a moment and think about what it would mean for two
> > independent Squeak images to be writing to the same changes file.
> 
> David, I did not mean to suggest two Squeak VMs write into the same changes 
> file, but the opposite - 
> 
> suggest a simple mechanism that would prevent a second Squeak process from 
> starting, when there is already another VM process running using the same 
> image+changes. 
> 
> This was described in the second part that was sniped. I believe this is how 
> this thread started (someone running two VM processes on the same image). I 
> believe anything like that can only be done from the VM, to make sure the 
> second VM exits before the changes file is even read. In any case, I don't 
> know anything about how Squeak VM works so should leave this to experts.
> 
> Thanks Milan
> 
> > I'm
> > actually not 100% certain that it can't be made to work, but it sounds a
> > bit shakey.
> >
> > Dave
>