David,

Thanks for your comments. Being new to Squeak (well have been playing with 
etoys for a while) and completely new to Smalltalk I do not think I feel 
confident to start coding in areas that are fairly deep down and could break 
things in a bad way... 

But in case having a simple way of preventing two VMs running over the same 
image would be viewed as something useful and practical to implement, I may 
give it a try in the next month or so, so a few points. I am a not 
knowledgeble whan it comes to VMs, booting Squeak etc so the terms are fuzzy, 
misc error hadndling ignored:
	
	- If done outside the VM, these "lock checks" would have to happen very early 
in the start process. 

	- Squeak VM starts execution

	- As early as possible, before any user interaction , and before anything 
like Services kick in (you are suggesting AutoStart>>startUp: is that 
correct), on the "main thread" (to prevent it from continuing while the work 
below is being done)
		- Check if "lock file" .MY_IMAGE_NAME-lock exists.
		  ifTrue: [read timestamp1 from it. wait 20s. read timestamp2.
			Check timestamp1 = timestamp2
			ifTrue: [lock must be left after crash, reuse lock file below, continue.]
			ifFalse: [ another Squeak VM process active, exit.]
			]
		- Spawn new Thread (#forkAt:?) which will:
			- create new .MY_IMAGE_NAME-lock unless reused from above
			- if create failed, another Squeak VM squeazed in after initial check, 
exit.
			- every 5s write a new Timestamp into .MY_IMAGE_NAME-lock
	- On user exit:
		- remove .MY_IMAGE_NAME-lock 
			(which part of Squeak  would this be?)

There would be probably bigger picture things to consider. For example , do 
people currently run Squeak in a directory where they have access to modify 
files (image, changes) but have no privileges to create a lock file .. 
probably more things to consider.

Milan

On December 8, 2004 06:17 am, David T. Lewis wrote:
> 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