schur@venera.isi.edu (Sean Schur) (01/14/90)
I have what I hope is a simple question. How do you kill processes running in the background on the Amiga? I have tried using the BREAK command (BREAK 5 ALL), but it never seems to work. Everytime I do a status command after a BREAK, the process is still there. Is there any other way to kill processes? I am used to UNIX where I can just use KILL. Thanks in advance. - Sean Schur
6600mld@ucsbuxa.ucsb.edu (Matthew Deter) (01/14/90)
In article <11397@venera.isi.edu> schur@venera.isi.edu (Sean Schur) writes:
I have what I hope is a simple question. How do you kill processes running
in the background on the Amiga? I have tried using the BREAK command
(BREAK 5 ALL), but it never seems to work. Everytime I do a status command
after a BREAK, the process is still there. Is there any other way to kill
processes? I am used to UNIX where I can just use KILL.
There is a program called abort which will do what you ask. Sort of.
Since the Amiga doesn't track all its resources (as I understand it)
the equivilent of Unix's KILL simply doesn't exist. Abort works very
well on tasks running in CLI windows, and will also kill off tasks
with screens, but it will not reclaim the screen (or the memory its
eating.) The program ought to be available on a local BBS, or maybe a
fish disk. If you can't find it, I'd be willing to mail you a copy.
Thanks in advance.
- Sean Schur
--
Matthew Deter | History will teach us, if we are |
6600mld@ucsbuxa.bitnet | willing to learn. Help end the | //
6600mld@ucsbuxa.ucsb.edu | prohibition of illicit drugs! | \X/ Amiga!davewt@NCoast.ORG (David Wright) (01/14/90)
Try using GOMF. It isa commercial package, but allows you to do much more than any PD program I have seen. You can use a utility that comes with it called "NUKE" or "RECALL" (I forget which) to selectively remove tasks AND their screens. Of course, and memory that the program allocated, that is not a screen, can't be freed, and locks can't be freed (but you can use the PD program "locks" to do that), but overall you do get vack a large portion of the memory. Especially if the program was large itself. Dave
sdl@lyra.mitre.org (Steven D. Litvinchouk) (01/17/90)
In article <1990Jan14.135851.9861@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: > Try using GOMF. It isa commercial package, but allows you to do > much more than any PD program I have seen. You can use a utility that comes > with it called "NUKE" or "RECALL" (I forget which) to selectively remove > tasks AND their screens. Of course, and memory that the program allocated, > that is not a screen, can't be freed, and locks can't be freed (but you can use > the PD program "locks" to do that), but overall you do get vack a large > portion of the memory. Especially if the program was large itself. I own GOMF 3.0, and I too am pretty pleased with it. However, three caveats: 1. Don't spend the extra money for the "GOMF Button." This is a piece of hardware (which costs extra) that is claimed to unfreeze a locked-up Amiga (non-responsive mouse pointer, etc.). In the year or so I've owned this contraption, I have *never* been able to recover successfully from system freeze-ups that occurred. (The only such recovery I can do is using GOMF's own demo disk, which artificially generates such a condition!) 2. GOMF itself is not perfect, and some programs (e.g. Less v1.3, SID) exhibit strange behavior when running on a GOMF-protected system. (Fortunately, you can terminate GOMF when running such programs, and then enable it again later.) 3. Hypertek/Silicon Springs (the original vendor of GOMF) is no longer taking telephone calls. Did they go under? Is another company marketing and supporting GOMF? Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mbunix.mitre.org UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Where does he get those wonderful toys?" -- J. Nicholson -- Steven Litvintchouk MITRE Corporation Burlington Road Bedford, MA 01730 (617)271-7753 ARPA: sdl@mbunix.mitre.org UUCP: ...{att,decvax,genrad,ll-xn,philabs,utzoo}!linus!sdl "Where does he get those wonderful toys?" -- J. Nicholson
uzun@pnet01.cts.com (Roger Uzun) (01/18/90)
I have GOMF 3.0, it has a lot of quirks, I do not recommend it.
It renders a 68030 system unstable. Seemed to work ok on an 020.
It can cause a lot more problems than it solves.
caveat Emptor
-Roger Uzun
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.comshimoda@prassl.UUCP (Markus Schmidt) (01/20/90)
In article <SDL.90Jan16151758@lyra.lyra.mitre.org> sdl@lyra.mitre.org (Steven D. Litvinchouk) writes: > >In article <1990Jan14.135851.9861@NCoast.ORG> davewt@NCoast.ORG (David Wright) writes: >2. GOMF itself is not perfect, and some programs (e.g. Less v1.3, >SID) exhibit strange behavior when running on a GOMF-protected system. >(Fortunately, you can terminate GOMF when running such programs, and >then enable it again later.) Hi! I remember a dicussion that appeared a time ago on the amiga.dev conference in BIX. The item was a low-memory violation and some people said, there's GOMF producing errors that other dedectors don't. There was also in dis- cussion, that GOMF might produce (and recover) errors, just to convice you, that it was a good purchase. -- "Take you dying with some seriousness, however, laughing | Markus Schmidt on the way to your execution is not generally understood | shimoda@prassl.UUCP by less advanced souls - they might call you crazy" | (from the "Messiahs Handbook") | Would you laugh?