In  [log in to unmask], [log in to unmask], <[log in to unmask]> writes:
 
> How is the father suspending itself in the beginning?  Are you
> explicitly specifying the SUSP mask or relying on the default?
 
Suspend(2);
 
> Is the son checking bits 29:2 for the suspension condition?  Maybe the
> father isn't awaiting re-activation from the son???
 
Yeah. I Getprocinfo on the father in the son process, print out nasty messages
if it's NOT suspended, then call activate, print out nasty messages if CC<>,
THEN getprocinfo on father AGAIN to make sure it says it's now awake...
 
> I had a problem like this (MPE/V) a _long_ time ago, and honestly I
> don't remember what was causing it (other than stupidity, that is) but
> I seem to recall that I wasn't explicitly telling everyone where to
> look for re-activation.
 
One of the things that makes me think it's a bug, is that I noticed already
that from MPE/iX 4.0->5.0 when I called suspend(2) the Getprocinfo flags were
WRONG (they showed 3 as I recall - waiting on either father or son). I had
code which checked processes before activating them to make sure they were
waiting on a Son to activate them (just in case), and that code all got blown
out of the water on 5.0.
 
(I'm cc'ing this to the list as well)
 
For background; the father has MANY son processes hanging off of it. The
father does a display before and after calling suspend(2) - I get the before
display but not the after. Not every time, but often enough to be REALLY
annoying. The son process also displays that it called Activate(0), got a CCE,
and even calls Getprocinfo to make sure the father is now activated. (Which
is really confusing, unless the father<->son pointers somehow got misdirected
to some other process?) or the process' status is updated but its never really
awakened...?
 
I'm open for suggestions...
 
                            -Chris Bartram
                             3k Associates