John,

I've noticed on Win32 that Squeak starts amazing fast if you provide it a parameter of the image you are starting (like no splash screen is necessary it is so fast). So why it takes so long when no parameter is provided and there is only 1 image file in the squeak folder, beats me. I just setup my shortcut to provide the parameter so I don't have to wait for startup.

Yep, thats great, but why ?

Strange, this should be looked into !

Aaron

If you drag and drop the image onto the VM, startup is instant. It's only when you double-click Squeak.exe that it can take >some time (due to some oddities in Windows).

If no one else is going to look into this I may at some point in the future, as I can see no real reason why it should be like that.

Unless someone experienced in Windows programming already has and it cannot be beat.

In Windows dragging the image to the exec causes another error message regarding not being able to write the changes file, atleast on my system anyway.

Aaron

...

...

If you drag and drop the image onto the VM, startup is instant. It's only when you double-click Squeak.exe that it can take >some time (due to some oddities in Windows).

Ehum, that sounds odd. Is the changes file writable? Do you have a changes file? The image and the changes file always comes in pairs.

okay this was because I had another instance of Squeak already running using the same image and changes image.

This may possibly be another issue altogether ?

Sorry to pick holes.

Aaron

Tim -

Think about the issues here - two copies of the same image running, recording changes to the same changes file. You open the changes file for write from the first image to get to a point where it records a change. You try to open the changes file again for the second image. Does your OS allow opening a file multiple times to write? Does it even allow opening to read once it's already open for write?

Actually it allows all of them. I made the decision for having an exclusive write lock on files opened with read-write since Squeak doesn't give us much control about the intended behavior and in the past I was bitten many a time by having different programs (or even the same program!) write to a file concurrently. This can actually be a problem if you know what you're doing but unless we have better control from Squeak directly I don't see any better solution.

Cheers, - Andreas

"Aaron Gray" angray@beeb.net wrote:

...

All in all I think it's safest to recommend not trying to run the same image multiple times.

Thats my point, but an average user is not necessarily going to understand the error message or click on ok and end up not being able to save any changes at a later point.

Yup. Not a good thing to happen.

Either disallow two uses of the same image or provide a second changes file.

T'would be nice, but how to implement it? The image file is closed after startup so we can't (?) detect the problem by looking for any attempt to multiple-read it. Maybe there is someway to lock the changes file to a particular process on some OSs? We can't do a 'set to only open once' without biggish changes in the image - I did try ages ago becasue _my_ OS doesn't let you open a file for read if it's already open for modify (which personally I think is a good thing). In the end I had to write an entire underlayer for my FilePlugin to fake it out. Not a fun job. Suggestions welcome.

Please ignore me.

Not whilst you're raising good points...

tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Logic is neither an art or a science but a dodge.

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

<geezer voice> Sonny boy, when I was your age. We had this new-fangled DOS program called "share.exe". It would keep track of the files you opened, and make sure they weren't opened again. The application programmers didn't have to do squat. Only problem was, when you got bit by a file-handle leak. =( </geezer voice>

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

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

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