HP3000-L Archives

August 2001, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steve Dirickson <[log in to unmask]>
Reply To:
Steve Dirickson <[log in to unmask]>
Date:
Sun, 19 Aug 2001 20:10:13 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
> That seems reasonable to me.  I drew my conclusion from a
> single pass, and as
> I've not had a lot of experience with this end of MPE, it
> wasn't, alas, as
> obvious to me is it is to you.  It is not inconceivable to me
> that a child
> process could be raised to live on its own after the death of
> its parent.
> Thanks for clearing up my confusion.

In the process-management area, this is one of the more significant
differences between MPE and, say, Win32. Once a Win32 process is created, it
lives independently of, and frequently much longer than, the process that
created it. The "parent/child" terminology is kind of unfortunate, as is the
use of "inherit" and "inheritable" in describing objects such as file
handles that may be passed from the creator to the new process. A "child"
process is really more of a peer-with-special-privileges.

In MPE, a "process tree" is really a tree (well, an upside-down tree); if
you cut off any piece of it, everything that "hangs from" that point
disappears. So, if you want to keep a process alive, you have to make sure
you keep all of its ancestors, whether you need them or not. On the other
hand, you don't have to worry about leaving dangling processes if you want
to terminate some higher-level process; MPE automatically "cleans up" for
you.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2