Often you want to terminate a program because it is not responding, if you do it the wayOriginally 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 wayOriginally 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 $
Last edited by dwks; 08-31-2006 at 04:30 PM.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
However it won't tidy up before it terminates, which I presume is what your would want to do.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.
dwk
Seek and ye shall find. quaere et invenies.
"Simplicity does not precede complexity, but follows it." -- Alan Perlis
"Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
"The only real mistake is the one from which we learn nothing." -- John Powell
Other boards: DaniWeb, TPS
Unofficial Wiki FAQ: cpwiki.sf.net
My website: http://dwks.theprogrammingsite.com/
Projects: codeform, xuni, atlantis, nort, etc.
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.Originally Posted by esbo
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
Last edited by esbo; 08-31-2006 at 04:54 PM.
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.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.
If you understand what you're doing, you're not learning anything.
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).Originally Posted by esbo
If you understand what you're doing, you're not learning anything.
> 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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.