[Openmcl-devel] relaunching CCL IDE on Windows problems

[Gary Byers]

It's generally easier to run multiple instances of GUI apps on Windows
than it is on OSX [*], but it doesn't seem to be possible to run multiple
instances of Cocotron GUI apps.  I don't know why not or whether that's
intentional; if it is intentional, there would probably be better ways
to detect the fact that another instance is running than waiting forever
for that other instance to release some global resource, which is what
seems to happen now.

(I have to admit that I haven't tried to run multiple instances of
non-CCL Cocotron applications in a long time, if ever.  If non-CCL
Cocotron applications behave differently and allow multiple instances
of themselves to run, then CCL should obviously stop doing whatever
it's doing that prevents that.  I don't think that's likely, but don't
know for sure.)

Assuming that this is a Cocotron issue, a fourth option would be to
figure out what Cocotron's doing that prevents multiple instances
of an application from (fully) running and:

a) fix it, if it's just a bug
b) if it's really intentional, do -something- besides hanging if another
instance is running.  (Exit with an error message, offer to kill the other
instance, ... anything.)

If you tried to pursue option 3, I think that that'd be less attractive.
It's conceptually straightforward to say "find all OS processes that have
the same name as the current OS process but different process identifiers
and kill them", but it's harder to believe that that's a good idea.  (Why
would you want to kill a copy of CCL that's running in Emacs ?  Why should
a healthy instance of your application die so that you should live ?  Does
this other process named "wx86cl.exe" have anything to do with CCL ?)

If you find that Cocotron GUI apps that're entirely written in ObjC behave
differently, then that would suggest that there may be a CCL issue here.
If there isn't a CCL issue here, then it would seem that something in
Cocotron's GUI initialization code needs to change (either to stop assuming
that only one instance of an app is running or to better handle the case
where that assumption is violated.)


----------
[*] Some applications - Web browsers - may really want to ensure that only
one instance of themselves is running.  As far as I know, they do this
by trying to create some uniquely named resource (a temp file or something
harder to spoof) on startup and destroying it on exit; if the resource
already existed, then they can conclude that there's either another instance
of themselves running or that a previous instance didn't exit cleanly.  Windows
isn't involved in any of this.

On OSX, it's harder for a GUI application to even get to that point.

On Wed, 16 Nov 2011, Alexander Repenning wrote:

> We have some problems with people trying to use CCL-based Win32 apps which
> can be traced back to CCL related processes hanging around. This may be the
> result of CCL improperly terminating in case of a crash. Here is one way to
> reproduce a similar situation:
> 
> On Windows XP
> 
> - build CCL IDE app by requiring wit Cocoa and saving app (With?1.8-dev
> ?(WindowsX8632))
> - launch?CCL IDE:
> - listener pops up (good)
> -?WaltConsole.exe and wx86cl.exe processes in Windows Task Manager (no
> problem so far)
> - assume CCL IDE did crash and left one of both processes alive
> - launch CCL IDE again?
> - NO listener will pop up (bad)
> - two more?WaltConsole.exe and wx86cl.exe processes in Windows Task Manager
> - repeat last step as many times as you want: each one will add processes
> 
> This is bad because these new processes have no interface: you will not get
> a Listener nor get to see that WaltConsole. Bottom line: if your CCL based
> app did crash and left some process you will not be able to relaunch your
> app. Some options:
> 
> 1) instruct users to scan windows task manger for?WaltConsole.exe and
> wx86cl.exe?processe and make the end these processes. Not a great idea.
> 2) have users reboot the machine to purge rogue processes. Not a great idea
> 3) have CCL check for?rogue?WaltConsole.exe and wx86cl.exe processes at
> launch an kill them preemptively (perhaps controlled by some mode)
> 4) ????
> 
> 
> Option 3 sounds actually pretty compelling given that at least so far there
> is no good reason to run multiple versions of CCL on the same machine. But
> how would we kill these processes and making sure we are not actually
> killing ourselves? Also, are there any alternative ideas how to avoid this
> issue?
> 
> thanks, Alex
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Prof. Alexander Repenning
> 
> 
> University of Colorado
> 
> Computer Science Department
> 
> Boulder, CO 80309-430
> 
> 
> vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf
> 
> 
> 
> 
>