[comp.lang.smalltalk] Suspended processes building up...

schang@netcom.UUCP (Sehyo Chang) (07/07/90)

In article <23841@estelle.udel.EDU> new@ee.udel.edu (Darren New) writes:
>
>This is about Smalltalk-80 VI2.5 from ParcPlace.
>
>When I load my image (which I have been using for several months)
>and execute "Process allInstances inspect" I have about 80 processes
>in Process>>suspend.  When I do it again, right away, I have about
>100 processes in Process>>suspend. I've noticed the performance getting
>slightly slower and I'm wondering if it is because of these
>instances.  I'm using a somewhat sloppy package that does not always
>kill all of its processes, but it suprises me that I get 20 new
>suspended processes just by running the one statement. Are these
>processes supposed to stick around?  Even after I GC, I still have
>five or ten new processes. None of the processes are active.
>
>On a side note, does anybody know how to find out the source
>for the method a process is running given the process? Is there any
>way of finding out who has pointers to these processes? 
>
>    Thanks in advance!     -- Darren


Normal St-80 has 5 process exactly(I could by off by one) at any time
unless you do '[...]fork' which creates new process naturally. Now
any properly written smalltalk code should kill off all process
it created and clear semaphores, etc.  When you have 80->100
process count increments means that your processes are creating
another processes (probably unpredicatable). Now to kill off all
processes (assuming you didn't fork process with higher priority
than userScheduledProcess), follow these steps:
	(1) enumerate over all process instances
        (2) check a process to see if it's priority is higher than
            userScheduledProcess, if not terminate it
        (3) invoke 'ScheduledControllers searchForActiveController
this will kill off all your processes, oh by the way, you have
to encapsulate these codes with [...] forkWithPriority: Priority
userScheduledPrority+1, otherwise you will kill yourself.

To find out all dangling object which point to your processes, open 
inspector on one of process and do 'Smalltalk collectPointersTo: self',
this will give you all object reference your process.  Now you can
clean up individually or change your code such that all your processes
are terminated automatically.  

When writing Smalltalk codes, it is very important to clean up objects
after using it otherwise you will get this accumulation of thrash objects.

Hope this helps...

kentb@argosy.UUCP (Kent Beck) (07/10/90)

On Tektronix' implementation of Smalltalk (and I believe the same holds
true for ParcPlace), allInstances can return "zombie" objects, objects
which are garbage but have not yet been collected.  Processor|yield does
a fork, creating a new process many times a second.  These processes are
scavenged quickly, but depending on how recently you have scavenged
there may still be many lying around.

Kent Beck