[ANN] Enhanced ImageLocker released

Dear all,

New version 2.0 contains few important enhancements:

- Locker quits now surely before other are notified with an
  #returnFromSnapshotEvent and before any user subsystem starts,
- timeout before shutdown a duplicated image is increased to 30 seconds,
- save as a new name will lock a renamed image while unlock old one.
- starting image with -unlock option from command line the ImageLocker
  can be temporary disabled just to be sure in case of any potential
  troubles with it.

What is ImageLocker? From the package comment:

ImageLocker lock an image to prevent that the other image with the same
name will accidentially start. That way a running of duplicate images is
prevented. Such run can namelly has a disastrous consequences.

Lock is managed by special file <imagename>.lock. If the same image with
the same name starts and finds this lock file locked, it wont start but
will quit in 30 seconds. If a lock file is there but unlocked (after an
image crash), it will won't quit but will be locked again. Quit can be
prevented by evaluating 'ImageLocker stop' before quit.  See Transcript
for the lock/unlock report and stop quit instructions.

ImageLocker can be temporary disabled by starting an image with a
-nolock option from command line (after the image name).  In case of
saving the image under a different name the old image will be unlocked
and one with a new name locked.

ImageLocker is implemented as a subclass of Subsystem, which is
activated (image is locked) immediatelly after this package/parcel is
loaded and deactivated (image is unlocked) when package/parcel is unloaded.

(c) Janko Mivsek, jun2010. License: MIT


Best regards
Janko

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 07/04/10 06:24, Janko Mivšek wrote: Very nice.  I noticed that, if the Transcript is obscured by another VW
window, it is difficult to tell what is going on during the 30 second
wait.  This might be frustrating for people (like my students) who are
very uneasy with Smalltalk.  How about, if the image is head-full,
showing a dialog?  I'm not really sure about this but I thought it was
worth a try....changeset attached.  Adds -nolockgui option for users
that prefer not to have the dialog.

David


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi David,

Thanks for this enhancement and yes, I'm also aware of that problem, but
I'm not sure if a GUI dialog is a right solution. In case of many images
starting in parallel how will you know, wich dialog is for which image?

I'm thinking more in the direction to refresh launchers during these
30s, so that the warning message will clearly be shown. Also after the
quit a message should be send on the standard error output to see the
reason of quit in console. How can I do that in VW?

Next thought, if we see the quit reason in console, do we need a timeout
and that ImageLocker stop at all? Not to confuse people with
instructions how to evaluate that stop command, what if we simply remove
that instruction from Transcript message? Remember that stoping the quit
sequence shall be rarely needed and there is already a -nolock in case
of any troubles.

Best regards
Janko

On 04. 07. 2010 18:32, C. David Shaffer wrote:
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 07/04/10 13:20, Janko Mivšek wrote:
> Hi David,
>
> Thanks for this enhancement and yes, I'm also aware of that problem, but
> I'm not sure if a GUI dialog is a right solution. In case of many images
> starting in parallel how will you know, wich dialog is for which image?
>  

I'm not sure it matters.  You just hit "Yes" I want to quit until there
are no dialogs left.  :-) I understand that this is a matter of taste. I
can maintain the GUI dialog as a patch for my students.  Overall I
really like ImageLocker, much better than my shell script.  Generally it
solves lots of problems which can frustrate students like, for example,
in our UNIX lab the student's images are on a network disk and they
often forget to log out (small school, big lab) and leave images open. I
realize that there are other use-cases here but I'm puzzled which ones
make the GUI dialog impractical:

1) VisualWorks developer sitting at workstation has image open on
another desktop.  The GUI works well here
2) Headless server image...no GUI here
3) Head-full server image...in this case the script which starts the
server should specify -nolockdialog because they certainly don't want one.
4) Application end-user...are there any use cases for fat-client VW
applications that would use ImageLocker?
5) Things I've left out...?

> I'm thinking more in the direction to refresh launchers during these
> 30s, so that the warning message will clearly be shown. Also after the
> quit a message should be send on the standard error output to see the
> reason of quit in console. How can I do that in VW?
>  
UnixIOAccessor stderr might be what you want but I'm not sure.

> Next thought, if we see the quit reason in console, do we need a timeout
> and that ImageLocker stop at all? Not to confuse people with
> instructions how to evaluate that stop command, what if we simply remove
> that instruction from Transcript message? Remember that stoping the quit
> sequence shall be rarely needed and there is already a -nolock in case
> of any troubles.
>
>  
The only reason that I can see for the delay is for them to have some
idea /why/ the image didn't launch.  I can imagine a lot of confusion
from people clicking away madly and wondering why their image didn't
open.  Again, I like the UI in this case but only for head-ful images,
of course...for headless images a message to stderr is fine.  Transcript
messages are automatically sent to stdout in headless images so this
problem is already solved by your code (although again, the wait is not
needed).

David
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc