[Pharo-project] Single instance executables
Hello all, I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening. Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas? Bill
On 02.09.2010 21:45, Schwab,Wilhelm K wrote:
Hello all,
I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening.
Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas?
Bill On Windows, it will give you an error that it was unable to open the changes file when you open the second image.
Cheers, Henry PS. I think Steph agrees, given his experience with updates that mysteriously contain seemingly random bits of other methods' source code :)
;) Stef On Sep 2, 2010, at 11:59 PM, Henrik Sperre Johansen wrote:
On 02.09.2010 21:45, Schwab,Wilhelm K wrote:
Hello all,
I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening.
Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas?
Bill On Windows, it will give you an error that it was unable to open the changes file when you open the second image.
Cheers, Henry
PS. I think Steph agrees, given his experience with updates that mysteriously contain seemingly random bits of other methods' source code :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I took that as agreement and created 2906. I don't know how to make it happen, but am certainly available for testing on Linux. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Friday, September 03, 2010 3:30 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Single instance executables ;) Stef On Sep 2, 2010, at 11:59 PM, Henrik Sperre Johansen wrote:
On 02.09.2010 21:45, Schwab,Wilhelm K wrote:
Hello all,
I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening.
Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas?
Bill On Windows, it will give you an error that it was unable to open the changes file when you open the second image.
Cheers, Henry
PS. I think Steph agrees, given his experience with updates that mysteriously contain seemingly random bits of other methods' source code :)
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You could open some file for write at image startup. When its failed you know that another image already started 2010/9/2, Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Hello all,
I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening.
Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Perhaps Denis meant the file would be deleted when the image is exited. So only the presence of the file would need to be checked for upon startup.. On Sat, Sep 4, 2010 at 5:40 AM, Douglas Brebner <squeaklists@fang.demon.co.uk> wrote:
 On 04/09/2010 08:25, Denis Kudriashov wrote:
You could open some file for write at image startup. When its failed you know that another image already started
That only works on Windows. Unix will allow you to open a file for writing multiple times simultaneously.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You mean like the change log? :) If that will work, then we should look close to home and take the hint. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Denis Kudriashov [dionisiydk@gmail.com] Sent: Saturday, September 04, 2010 3:25 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Single instance executables You could open some file for write at image startup. When its failed you know that another image already started 2010/9/2, Schwab,Wilhelm K <bschwab@anest.ufl.edu>:
Hello all,
I realize that I hold an unpopular position on this, but it *will* come back to haunt us: we need to have a way to warn the user if a second copy of Pharo is launched. Random meltdowns and lost work will result from the current behavior. Let me be more bold: lost work and random corrrupted images *are resulting* from the current behavior; they are either unrecognized, or simply ignored, but it is happening.
Is there a way to fix it? On Windows, I recall creating an OS semaphore with a given name and if that exists, bail out before the session even gets going. We would need a cross-platform way to do that (or at least a Linux/Mac way to do it - Windows has a mechanism), and then a place to abort startup early enough to prevent problems. Any ideas?
Bill
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Chris Muller -
Denis Kudriashov -
Douglas Brebner -
Henrik Sperre Johansen -
Schwab,Wilhelm K -
Stéphane Ducasse