[squeak-dev] How to get rid of instances of ExternalUnixOSProcess

David T. Lewis lewis at mail.msen.com
Thu Feb 5 04:07:56 UTC 2015

On Wed, Feb 04, 2015 at 11:04:06AM +0100, Herbert K?nig wrote:
> Hi Dave,
> >All of the child processes that run in your current Squeak session (beginning
> >when you start the image) are saved in a dictionary. This is just to make
> >them browsable (OSProcess thisOSProcess allMyChildren).
> >
> >Unregistering each child process, as you suggest above, will work fine, at
> >least after fixing the bug that you found (thank you for that, it is updated
> >on squeaksource now).
> >
> >But you can also clean up all of the terminated processes like this:
> >
> >   OSProcess thisOSProcess discardExitedChildren
> >
> >Or you can empty the dictionary completely:
> >
> >   OSProcess thisOSProcess resetChildProcessDictionary
> thanks, these helped a lot.
> >process every few seconds, maybe for a long time) I can see that it might
> >be a real problem. Do you think that this should be changed?
> I have been doing embedded with scarce RAM and now I play with home 
> automation (in a very broad sense) which is supposed to run 24/7 me 
> being abroad and my family not programming.

I see what you mean! It would be rediculous to accumulate all of the
process proxies in this case.

> From this perspective my immediate instinct is to not collect the 
> instances at all.  Now that I know about the fact I prefer to remove 
> them myself. But I'm sure other users have a different perspective on 
> this and you might break somebody's code if you wouldn't collect them at 
> all.
> I former uses I collected the processes myself (to kill them, query 
> their state) and for that purpose wouldn't want to pick them out of a 
> dictionary.

As a quick and dirty workaround, you might want to just modify
UnixProcess>unregisterChildProcess: to make it do nothing at all.
That would be a hack, but you have no real need for the child process
registry anyway, so that would be an easy way to make the problem go
away for your home automation application.

Meanwhile, I'll see if I can come up with more sensible solution.

> I'm very interested in learning when this dictionary comes in handy or 
> is needed because I see many methods referencing allMyChildren but most 
> of them are not sent in my image so I can't find out.

Well, when I wrote OSProcess/CommandShell, it was sort of an experiment
to figure out if I could wrap various functions of common operating
systems (not just Unix) in such a way that they could be accessible
from Squeak. I wanted to be able to browse the objects that represented
those OS functions, and I wanted to be able to watch the proxy objects
change state as external processes ran and then exited. I figured that
an object that represents the current OS process (the one in which your
Squeak VM is running) should be able to know about the child processes
that it creates. So I added a child process registry to keep track of
this. When the image started, the registry would be empty, and as time
goes on and you run various child processes using OSProcess, the proxies
for those child processes are maintained in the registry dictionary.

None of this has any practical application that I know of, but it fit in
with my idea of having an abstract representation of OS process functions
that can be viewed and manipulated directly from the Squeak image.


More information about the Squeak-dev mailing list