Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!amdcad!ames!pasteur!agate!ucbvax!MAILGW.CC.UMICH.EDU!rees
From: rees@MAILGW.CC.UMICH.EDU (Jim Rees)
Newsgroups: comp.sys.apollo
Subject: Re: Suspending processes (was questions for the gurus)
Message-ID: <8809161523.AA07601@mailgw.cc.umich.edu>
Date: 16 Sep 88 15:15:43 GMT
References: <dbfunk@icaen.uiowa.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: rees@caen.engin.umich.edu (Jim Rees)
Organization: The Internet
Lines: 21


        If a process is given a fault_$suspend_proc signal it will stop
    execution until it receives a fault_$continue_proc signal (look
    in /sys/ins/fault.ins.{pas,c,ftn} for their definition). To give
    one of these signals you will have to use /com/sigp with the "-c"
    option. EG: '$ sigp -c 120027 process_151' will cause process_151
    to stop execution.

Another way to do it would be with "kill -STOP".

        The DM 'ds' and 'dc' commands use undocumented system calls to suspend
    and continue a process. These work in the kernal and actually change the
    process manager dispatch status. This will show up in a pst state as 'Susp'.
    This is safer as a 'dc' cannot be blocked by another signal but the process
    must be continued before it will respond to any signal.

You've got this backwards.  "dc" is the more dangerous way.  Since it's a
kernel thing, it ignores user space locking.  If you happen to suspend a
process this way while it's holding some important user space lock (like
the tcp mbuf lock or a DM streams sfcb lock) you can hang the whole node.
-------