Thanks for that info. But I vaguely remember deliberately making zombies with Learning Works. But 
I'm sure it is more relevant to a system than an application. I find it hard to take that the course team 
would have just stuffed a Unix term into Smalltalk unless it had already been adopted by the 
Smalltalk world such as on a system like the Alto.

And after all Squeak is working like an OS on top of an OS.

Regards
Gary

25/02/02 23:29:57, "David T. Lewis" <lewis at mail.msen.com> wrote:

>On Mon, Feb 25, 2002 at 06:38:46PM -0000, Gary McGovern wrote:
>> I'm also interested to know the origin of zombie and its relevance to Squeak. My "guess" is yes 
for 
>> MVC and no for Morphic. Anyone know ?
>
>The term "zombie" has a very specific, if somewhat whimsical, meaning
>for a Unix operating system. On Unix, every process is created ("forked")
>by a parent process. The parent process is expected to wait for its
>child to exit, after which the parent collects certain statistics about
>the completed child process. When a child process has executed the exit()
>system call, but its parent has not yet collected those statistics, the
>child process is said to be in the "zombie" state. Think of it as a
>process which as died but has not yet left this world.
>
>This has no connection whatsoever to Squeak or Morphic. Well, maybe a
>very slight connection: If you are using OSProcess for Squeak on a
>Unix system, you will see that any external process which you create
>from Squeak gets cleaned up by a Smalltalk process when it exits
>(UnixOSProcessAccessor>>grimReaperProcess). If the grimReaperProcess
>was not there, you would have zombies every time you started an
>external process from Squeak. In other words, the child processes
>would exit, but no parent process would clean up after them, and they
>would hang around as "zombies" forever.
>
>Dave
>
>(how's that for topic drift?)
>
>
>