On Sat, 30 Jun 2001 16:51:16 -0400 (EDT) Rosemary Michelle Simpson rms@cs.brown.edu wrote:
FWIW, 34 processes seems like a very high number. Have you repeated the example you gave 20 or 30 times?
It gets even stranger. (1) the number of processes goes up and up and then down - it went as high as 85 and as low as 20. (2) doing DoIt on (self at: n) terminate for the processes labeled "a Process in UndefinedObject>>DoIt" turns the comment to "a Process in nil" but even doing that to all has not gotten rid of the clock and new processes seem to be being spawned. I feel like the sorcerer's apprentice... Of course, I could trash this image and bring in another from the CD, but I want to understand how to work with the processes.
Rosemary,
The problem is that ProcessorScheduler>>yield creates a new, but very short-lived, process and this may happen very often. In order not to see these guys, which are really dead and soon-to-be-garbage-collected, inspect the following two lines as a single unit:
Smalltalk garbageCollect. Process allInstances.
A clean image will have around 8 or 9 processes.
Cheers, Bob
Bob Arning wrote:
The problem is that ProcessorScheduler>>yield creates a new, but very short-lived, process and this may happen very often.
I submitted a trivial primitive that completely obviates this minor irritation some time ago.
tim
squeak-dev@lists.squeakfoundation.org