keith@bsovax.UUCP (Keith Dixon) (11/09/88)
Can anyone tell me what the difference is between a 'dead' status and a 'condemned' status in an OS-9 Process Descriptor ?? I am modifying a driver, and have found one or two bits that are not clear. Keith Dixon.
davely@mcrware.UUCP (Dave Lyons) (11/11/88)
In article <292@bsovax.UUCP>, keith@bsovax.UUCP (Keith Dixon) writes: > Can anyone tell me what the difference is between a 'dead' status and a > 'condemned' status in an OS-9 Process Descriptor ?? A process that is condemned has been marked to be exited by the Kernel. This is usually the result of a process receiving a deadly signal like keyboard quit or keyboard interrupt. Drivers and/or file managers typ- ically check for condemned processes after a sleep so that they can abort io on a process that is dying. A dead process on the other hand is one that has finished dying in that all its resources (paths, memory, etc.) have been released. The Kernel keeps around the "dead body" until the parent process can be notified. You really shouldn't have to concern yourself with dead processes in a driver since the process will be comp- letely through using the io system by the time it is dead. I hope this explanation helps. Dave Lyons -------------------------------------------------------------- | The above is a Dave Lyons production so Microware is not | | to be held responsible for it. | --------------------------------------------------------------
pete@wlbr.EATON.COM (Pete Lyall) (11/11/88)
In article <292@bsovax.UUCP> keith@bsovax.UUCP (Keith Dixon) writes: >Can anyone tell me what the difference is between a 'dead' status and a >'condemned' status in an OS-9 Process Descriptor ?? A 'DEAD' (or 'zombie' in Unix terms) is a process that has terminated, has closed its files and returned its system resources (i.e. code & data space), but has been unable to notify its parent of its death yet. In order for the parent to be in a position to recognize the death, it must issue a f$wait system call. The child will remain 'DEAD' until either the parent does the f$wait, or the parent dies. If the child has no living parent (PPID = 0), it will not bother attempting to notify anyone. I'm not positive about the condemn state, but I believe it's the case where a process's death is pending, but I/O still needs to be flushed (or something like that). Again - I'm not sure on the condemned state. Pete -- Pete Lyall (OS9 Users Group VP)| DELPHI: OS9UGVP | Eaton Corp.(818)-706-5693 Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud) Internet: pete@wlbr.eaton.com UUCP: {hacgate,jplgodo,voder}!wlbr!pete
knudsen@ihlpl.ATT.COM (Knudsen) (11/12/88)
Maybe you can help with a fundamental design problem of OS9. There are certain processes that just can't be killed or even made to shut down. Often the XCom9 terminal program will get hung because ACIAPAK driver screws up (yes, we all know that driver is obsolete and replacements are available). You can go to another window and KILL the xcom9 process. But not only does it not die, it goes into a tight loop of system calls (as measured by the increased sparklies snow on the Coco-3 screen). The "zombie" shows status 128. It won't die because it has open I/O to ACIAPAK, and you can't close or de-iniz /T2 because it has a process open to it. So this stalemate keeps the process from being killed, and also ties up your RS232 pak. So hit the button and re-boot. (Sometimes you can kill the process by de-inizing its window or unlinking it several times. Other times this crashes the system.) I heard that someone (Kevin Darling?) wrote a "Blast" utility that will silver-bullte kill anything and break the stalemate. Anyone try this? -- Mike Knudsen Bell Labs(AT&T) att!ihlpl!knudsen "Lawyers are like nuclear bombs and PClones. Nobody likes them, but the other guy's got one, so I better get one too."
koonce@brahms.berkeley.edu (tim koonce) (11/12/88)
In article <7609@ihlpl.ATT.COM> knudsen@ihlpl.ATT.COM (Knudsen) writes: >Maybe you can help with a fundamental design problem of OS9. >There are certain processes that just can't be killed or even >made to shut down. Often the XCom9 terminal program will get >hung because ACIAPAK driver screws up (yes, we all know that >driver is obsolete and replacements are available). [Stuff deleted] >-- >Mike Knudsen One thing I've done several times is to start another copy of XCom9 on top of the old one. It doesn't start successfully (it hangs immediately), but after <Break>ing to kill it, both are gone. It appears that sometimes attempting to grab the device from under the hung program dislodges it. (Maybe the driver recognizes the DEAD status, anyone know how this works?) - Tim Koonce