Often you want to terminate a program because it is not responding, if you do it the wayQuote:
Originally Posted by s1mon
you describe chances are it will not work.
Often you want to terminate a program because it is not responding, if you do it the wayQuote:
Originally Posted by s1mon
you describe chances are it will not work.
If I want to terminate a program because it is not responding, I send it a SIGKILL signal. Simple as that.
[edit] SIGKILL cannot be ignored. It will terminate any program (in theory).
[/edit]Code:$ jobs -l
[1]+ 3333 ls -R / &
$ kill -SIGKILL 3333
$
[1]+ ls -R / &: Killed
$ jobs
$
However it won't tidy up before it terminates, which I presume is what your would want to do.Quote:
Originally Posted by dwks
If it's responding, it will respond to a SIGTERM. If it's "not responding", a SIGTERM wouldn't work in any case, so even with your code you'd need to use a SIGKILL.
When a program has gone into a failure state where it's not responding, it is not reasonable to expect it to be able to clean up anyway.Quote:
Originally Posted by esbo
Quote:
Originally Posted by dwks
Usually a program which is 'not responding' will respond to a sigint if the signal handler is programed in a sensible way, similar to the way I described, ie not returning back to the
main program. If you programmed it in the way with the 'stop' flag then when it was 'not
responding' sending it a sigint would be a waste of time.
It is that is what signal handlers are for. However if you are going to program your signal handler in a completely ineffective way, then yes you would be right to believe it is unreasonable for it to be able to clean up.Quote:
Originally Posted by CornedBee
If your program goes into "not responding" then you have a bigger problem than dealing with clean up. The "correct" way is, as numerous people have already told you, to set the global variable and return to where the interrupt happened.
Just because it works in your environment, it doesn't make it right. And on this forum, we try to stick to the right way to do things.
I suppose next you're going to start telling people to use fflush(stdin) to clear the input buffer just because you've never had a problem with it.
One way of finding out which way is right is by testing, I suggest readers try both methods
and make their own minds up No doubt I will be proved wrong ;)
I see your idea of accuracy and efficiency is lacking. You can either test the method in every known environment and maybe get the correct answer (your way), or just refer to the standard (our way).Quote:
Originally Posted by esbo
> The program should be structured such that the signal handler can tidy up any loose ends.
Really - and if the program was in the middle of updating a double linked list, and you manage to get the ctrl-c between updating the two pointers, how on earth is the signal handler supposed to know what state the linked list is it?
It can't find the problem, can't repair the problem and if it tries to follow it, then your SIGINT is gonna look a lot like a SIGSEGV for something.
> One way of finding out which way is right is by testing
No, the right way is to understand the fundamental issues, not find some cack-handed "works for me" answer. The longer it "works for me" before it "doesn't work for me anymore", the harder it becomes for you to even see there is a problem, along with the blame the compiler, blame the tools, blame anything but the PICNIC.
> All the programs I have written with signal handlers...
Ah yes, more extrapolating the entire universe from one small piece of cake.
Your vastly limited experience doesn't mean everyone else can get away with the slop you write.