When BREAK <task> doesnt
20 messages in this thread
Is there a utility program that will allow me to kill errant tasks?
Sometimes I will have a program that will get out of control (ie fail to
respond to console input) I can find the task with STATUS but BREAK has no
effect on it. What other tools/techniques are there to deal with this ?
Thanks Russ
– via Whap!
There's a program called Amiga Real Time Monitor (ARTM) that does
that. I dont't know if it's in the libraries tho. If it isn't drop me
a message and I'll post it. I always use the program to close open
ports and windows when I am writing an Arexx program that quit with
some error and didn't go to the routine that closes everything. You
can easily close tasks and windows with it, just clock on task, click
onm remove, thats it.
I use a program called STOP. It will list your tasks and ask which one to
kill. It will exit without killing if you want. It will also kill or leave
the window or screen if you want.
As an aside (not really a comment to your message), it would be very nice
if people would start writing programs that responded to the
SIGBREAKF_CTRL_C signal.
For instance, all of the programs I've written lately respond to a break
signal by quitting, no matter what they're doing (unless they are crashed,
which is what you wanted). If this means closing 8 windows and aborting a
couple of documents, well, that's what the user asked for, so it shuts
things down and leaves.
It's not a difficult thing to do – just do checks like
if (SetSignal(0,0)&SIGBREAKF_CTRL_C)
exit(0);
and have an atexit() function do the cleaning up of whatever was opened.
Enough of the soapbox.. 😎
Hi, Steve,
Nice to see you here again.
Betty
Excellent point steve. One thing to remeber is that you should make sure
that your signals are clear to start with. If you are in the middle of an
important operation, it might also be nice for an application to make sure
that the User really wants to discard the data it had created…
John A. Toebes, VIII – via Whap!
Something else that too many Amiga programs do, is create data files, but
if the user aborts during the creation, they leave incomplete files lying
around.
The most notable example is the SAS C compiler – if you interrupt the
compiler in the right place, it will leave bad object modules lying around.
Plenty of other programs do the same thing.
So, if you do check for a break, delete the file you're in the process of
writing.
(If everything supported the Ctrl-C break, then we could have a program
that would show running programs, even if they had no windows open, and ask
them to abort. Commodities lets you do this, but with a fair amount of
commodities overhead).
…Steve
Steve, I have to disagree — I don't think I'd be much impressed with a
terminal program that aborted on a ctrl-C.
-sja
Taking this a step further (and resulting in an 'offical' enhancement
request to CBM), how about a system message to do the same thing. A good
example is when a UPS (uninterruptable power supply) notifies a system that
it is on batteries and has 5 minutes left. A system generated shutdown
message could tell all tasks to inform the user, cleanup gracefully, and
quit. An immediate form of the message that bypasses polite requesters
would be used when there is a short time left or for non-user tasks. I
know it could be done with Arexx, but I like the idea of this being
built-in the OS.
That's a good idea – but it requires the app to have more overhead that it
might not have had otherwise (creating a message port, basically). It
looks from exec/tasks.h that there are 11 system signal bits that aren't
yet defined – using one of those to mean SIG_SHUTDOWN would be a nice way
to do it. (Oops – 4 more defined for the DOS signansl.. that leaves 7
undefined).
…Steve
What is wrong with using any of the other 3 SIGBREAKF bits? That way
something like ^F from the keyboard would mean kill the task dead. Look at
what AmigaTeX does.
John A. Toebes, VIII – via Whap!
Because the Ctrl-C signal is traditionally used as a Please Quit signal.
The compiler sets every program that uses stdio up to quit when the user
hits Ctrl-C – I'm just proposing that the same thing apply to programs that
don't use the console for output.
…Steve
Ah in this case it does make sense. I agree that ^C should always mean ^C,
BUT it must clean up in a manner that doesn't lose things. Of course, a
Terminal package that exited when I typed ^C won't get much use out of
me… (Looks like I definitely need that Look at the previous message
capability out of Whap so I don't always feel like I am dropping in on the
middle of a conversation).
John A. Toebes, VIII – via Whap!
Of course the program should clean up when it gets a ^C. I'm not saying
the program should just exit without closing it's windows, freeing it's
resources, etc… My UserEdit program for BBX can open about 8 windows –
and if you BREAK it's process, it will shut them all down and quit.
I've seen programs that just vanish when you hit Ctrl-C – usually programs
that use stdio stuff, but also open windows. That's one of the reasons all
my cleanup code goes into a function that gets called at exit time (via
atexit()).
…Steve
Well then why would you send it a break signal?
I'm not talking about typing Ctrl-C to break something, I'm talking about
SetSignal(0,0)&SIGBREAKF_CTRL_C being true.
It takes some kind of conscious action to do that… and when would a
program be wrong to respond by quitting?
…Steve
But there is no difference between ^C and SIGBREAKF_CTRL_C from the
application level.
John A. Toebes, VIII – via Whap!
Only if you're running in a CON: window – but when was the last time you
ran a terminal in a console window?
BBX will quit if it gets a break signal. BBX uses the console.device for
it's screen IO, but hitting Ctrl-C doesn't set the break signal.
…Steve
Steve, Ok, looks like I did misunderstand what you were suggesting.
However, now I don't understand what you're suggesting. If you don't mean
a program shutdown from an external event, what do you mean?
-sja
I do mean a program shutdown from an external event. The external event is
the setting of the SIGBREAKF_CTRL_C task signal bit – which doesn't
necessarily mean a Ctrl-C.
A terminal program would obviously pass a Ctrl-C on to the system you were
connected to – but if I did a STATUS in a CLI window, saw that the terminal
was process 3, and said BREAK 3, I want the terminal program to quit.
…Steve
Steve, Ok, thanks for clearing up my confusion (well, at least that part of
it, confusion is a normal state of mind for me — something to do with
growing up in the 60s). I agree with your suggestion — maybe it should be
more of a suggestion and carved in stone in the style guide?
-sja