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@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