On Wed, Nov 28, 2007 at 06:48:42PM -0500, Jon Hylands wrote:
> On Wed, 28 Nov 2007 11:08:27 -0500, Jon Hylands <jon at huv.com> wrote:
> 
> > So it looks like the release for dependents isn't working in
> > OSProcessAccessor >> #startUp:
> 
> So, it looks like a bug. I changed: ThisOSProcess >> #initialize
> 
> It used to say:
> 
> processAccessor removeDependent: self.
> 
> and I changed it to say:
> 
> processAccessor breakDependents.
> 
> The problem is that if you're running on a different OS, the receiver is
> not the dependent. The receiver is actually an instance of WindowsProcess
> when the image is saved, but when it is resumed, it gets replaced by an
> instance of UnixProcess. The process accessor has the windows process as a
> dependent, so the removeDependent: call does nothing.
> 
> Hopefully David will read this and figure out how to fix it properly...

Hi Jon,

Thanks for the bug report and fix. I probably can't look into this for
a few days but will do so this weekend. I do recall that:

- Moving images between unix and windows is supposed to work. Maybe I
bolluxed something up in the more recent releases and forgot to test.

- As you noted, the singleton instance of the process accessor gets
replaced when you start the image on another platform. The fact that
you had an instance with dependents that were proxies for both unix
and windows external processes indicates that the replacement must not
have worked.

- I have had problems with loading new OSProcess versions on top of
old ones, with the resulting load not being properly initialized. If
this might be your situation, the easy fix is to remove OSProcess 
from your image entirely and reload from SqueakMap/Universes. You may
have to stop and start your image once to get everything healthy.

- Other problems that I have encountered with moving images between
platforms and/or loading new versions of OSProcess on top of old ones
have to do with the grimReaperProcess getting messed up or terminated.
The process accessor singleton keeps this process running (look for
it in the process browser) to watch for child process exit events.
When an external child process exits, it signals a Squeak semaphore
(via the OSPP plugin) and the grimReaperProcess cleans up the external
process and updates the run state of its OS process proxy in the image.
If you are seeing OS processes (OSProcess thisOSProcess allMyChildren)
that never get to runState of #complete, then the grimReaper process
is probably tangled up in its shorts. Kill it and restart the image,
or reload OSProcess as per above.

Dave