Thread: stop an executing C program and finish executing additonal line of code

  1. #31
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by s1mon
    Why? The signal handler should do as little as possible - for example, changing a global variable. Then it is your main code's job of checking for that variable. The op can just break out of the loop and proceed with shutdown code on a signal. Otherwise, every time you make changes to your code, you need to change the signal handler code.

    However, doesn't signal() only need to be executed once for each signal you want handled, not repeatedly in the loop?
    Often you want to terminate a program because it is not responding, if you do it the way
    you describe chances are it will not work.

  2. #32
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    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).
    Code:
    $ jobs -l
    [1]+ 3333 ls -R / &
    $ kill -SIGKILL 3333
    $
    [1]+ ls -R / &: Killed
    $ jobs
    $
    [/edit]
    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.

  3. #33
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by dwks
    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).
    Code:
    $ jobs -l
    [1]+ 3333 ls -R / &
    $ kill -SIGKILL 3333
    $
    [1]+ ls -R / &: Killed
    $ jobs
    $
    [/edit]
    However it won't tidy up before it terminates, which I presume is what your would want to do.

  4. #34
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    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.

  5. #35
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by esbo
    However it won't tidy up before it terminates, which I presume is what your would want to do.
    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.
    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

  6. #36
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    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.

    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.

  7. #37
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by CornedBee
    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.
    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.

  8. #38
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,218
    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.

  9. #39
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    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

  10. #40
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,218
    Quote Originally Posted by esbo
    One way of finding out which way is right is by testing
    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).
    If you understand what you're doing, you're not learning anything.

  11. #41
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > 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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Validating the contents of a char buffer
    By mattz in forum C Programming
    Replies: 3
    Last Post: 12-09-2001, 06:21 PM