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

This is a discussion on stop an executing C program and finish executing additonal line of code within the C Programming forums, part of the General Programming Boards category; Can't you just have a specially-crafted packet that represents end-of-data or whatever? When the server receives that, it breaks out ...

  1. #16
    Gawking at stupidity
    Join Date
    Jul 2004
    Location
    Oregon, USA
    Posts
    3,162
    Can't you just have a specially-crafted packet that represents end-of-data or whatever? When the server receives that, it breaks out of the loop.
    If you understand what you're doing, you're not learning anything.

  2. #17
    Registered User
    Join Date
    Aug 2006
    Posts
    14
    esbo: No, I'm not doing a thesis in CS. :-) I'd be in big trouble!

    I can trap ctrl+c? sweet. Thats all I would need. I did some googling, and this is what I came up with:

    http://c-faq.com/osdep/sigint.html

    Will the above work? I tried to impliment it, but cannot get it to work. This is what I have written so far:

    Code:
    #include <stdio.h>
    #include <signal.h>
    
    extern void do_this_last( int );
    signal( SIGINT, do_this_last );
    
    int main(){
        while( 1 ){
            printf( "doing stuff\n" );
        }
    }
    
    extern void do_this_last( int a ){
        printf( "finished!" );
    }
    I've never "trapped" anything, so I'm not sure where "signal( SIGINT, do_this_last )" should go.. And also, after execution of do_this_last, does it pop back into while( 1 ) loop? thanks!

  3. #18
    Registered User
    Join Date
    Aug 2006
    Posts
    14
    itsme86: Its not a question of when the data stream ends. I don't know until I'm in the middle of running the hardware.

  4. #19
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by darkwalk
    esbo: No, I'm not doing a thesis in CS. :-) I'd be in big trouble!

    I can trap ctrl+c? sweet. Thats all I would need. I did some googling, and this is what I came up with:

    http://c-faq.com/osdep/sigint.html

    Will the above work? I tried to impliment it, but cannot get it to work. This is what I have written so far:

    Code:
    #include <stdio.h>
    #include <signal.h>
    
    extern void do_this_last( int );
    signal( SIGINT, do_this_last );
    
    int main(){
        while( 1 ){
            printf( "doing stuff\n" );
        }
    }
    
    extern void do_this_last( int a ){
        printf( "finished!" );
    }
    I've never "trapped" anything, so I'm not sure where "signal( SIGINT, do_this_last )" should go.. And also, after execution of do_this_last, does it pop back into while( 1 ) loop? thanks!

    Well you look like you are in the right 'ball park', control C might not generate sigint, it depends
    on the system etc.... you should be able to sort it out from there, find an approopiate signal.

    Not sure why you use extern or have an int as a parameter to do this last.
    Might as well drop the void too, waste of 4 keystrokes!!!

  5. #20
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Get off the forum esbo. You're no help to anyone, and I'm getting tired of correcting you.


    To the OP, you can't have global function calls. signal is a function call. Try moving your signal call inside main, before your loop. What you're doing is setting up a signal handler before you need it. Then once it triggers, you check to see what's going on.

    To moron, the reason they have the function taking an int, is because that's what signal expects the function it gets passed to have for arguments. man signal


    Quzah.
    Hope is the first step on the road to disappointment.

  6. #21
    Registered User
    Join Date
    Aug 2006
    Posts
    14
    woot! it works. Here's what I have:

    Code:
    #include <stdio.h>
    #include <signal.h>
    
    void do_this_last( int );
    int stop;
    
    int main(){
        extern int stop;
        stop = 1;
        while( stop ){
            printf( "doing stuff\n" );
            signal( SIGINT, do_this_last );
        }
    }
    
    void do_this_last( int a ){
        extern int stop;
        printf( "finished!" );
        stop = 0;
    }
    The whole "stop" variable kindda sux though. There must be more elegant way of doing it.. :-) But thanx everyone for all the help! You guys are the greates!

  7. #22
    Registered User
    Join Date
    Aug 2006
    Posts
    14
    Thanx quzah!

  8. #23
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by darkwalk
    woot! it works. Here's what I have:

    Code:
    #include <stdio.h>
    #include <signal.h>
    
    void do_this_last( int );
    int stop;
    
    int main(){
        extern int stop;
        stop = 1;
        while( stop ){
            printf( "doing stuff\n" );
            signal( SIGINT, do_this_last );
        }
    }
    
    void do_this_last( int a ){
        extern int stop;
        printf( "finished!" );
        stop = 0;
    }
    The whole "stop" variable kindda sux though. There must be more elegant way of doing it.. :-) But thanx everyone for all the help! You guys are the greates!
    Rather than the stop bit I think an exit(0) at the end of the do_this_last function would be a
    tad more elegant.
    Also the signal function would be better before the start of the loop, you only need call it once.
    Anyway you seem to making progress!
    Last edited by esbo; 08-31-2006 at 02:56 PM.

  9. #24
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Just ignore esbo--actually that's a really good idea. Put him on your ignore list, he's an idiot.

    The point of the stop is so they can handle all of their clean up when they need to. So they can jump out of the loop on a condition, free memory if needed, etc. If you actually read the first reply, you'd see that they mentioned that as their intent already.


    Quzah.
    Hope is the first step on the road to disappointment.

  10. #25
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by quzah
    Just ignore esbo--actually that's a really good idea. Put him on your ignore list, he's an idiot.

    The point of the stop is so they can handle all of their clean up when they need to. So they can jump out of the loop on a condition, free memory if needed, etc. If you actually read the first reply, you'd see that they mentioned that as their intent already.


    Quzah.
    It is normal for the signal handling routine to take care of what needs cleaning up and then exit.
    Please do ignore me, it will save me having to listen to the abuse in your posts. Also thanks for reminding me of the facility, it will come in useful for me too!!

  11. #26
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,437
    > Rather than the stop bit I think an exit(0) at the end of the do_this_last function
    Signal handlers are a restricted environment, there's only a small subset of functions you can reliably call within a signal handler - printf() and exit() are not normally in that list.

    http://www-128.ibm.com/developerwork...y/l-reent.html
    http://www.mkssoftware.com/docs/man3/api_intro.3.asp (ie, Async-signal-safe)

    The manual pages for your system should tell you which functions are signal-safe and which are not. If it doesn't say, assume it isn't.

    In fact, setting an atomic global variable like an int is about the safest thing you can do.

    > int stop;
    Should really be
    volatile int stop;

    because...
    > stop = 1;
    > while( stop )
    On seeing this, the compiler may think there is no possible way that stop can change (it doesn't know about signal handlers) and perform a one-time substitution at compile time giving you
    while ( 1 )

    Your variable changes on the signal handler, but no one is listening!

    The volatile keyword ensures the compiler will look at the variable every time it should look at the variable.
    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.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  12. #27
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by Salem
    > Rather than the stop bit I think an exit(0) at the end of the do_this_last function
    Signal handlers are a restricted environment, there's only a small subset of functions you can reliably call within a signal handler - printf() and exit() are not normally in that list.

    http://www-128.ibm.com/developerwork...y/l-reent.html
    http://www.mkssoftware.com/docs/man3/api_intro.3.asp (ie, Async-signal-safe)

    The manual pages for your system should tell you which functions are signal-safe and which are not. If it doesn't say, assume it isn't.

    In fact, setting an atomic global variable like an int is about the safest thing you can do.

    > int stop;
    Should really be
    volatile int stop;

    because...
    > stop = 1;
    > while( stop )
    On seeing this, the compiler may think there is no possible way that stop can change (it doesn't know about signal handlers) and perform a one-time substitution at compile time giving you
    while ( 1 )

    Your variable changes on the signal handler, but no one is listening!

    The volatile keyword ensures the compiler will look at the variable every time it should look at the variable.
    The trouble with an approach like that is that you risk not being able to close down the program
    if the program has encountered a problem. The program should be structured such that the
    signal handler can tidy up any loose ends.
    All the programs I have written with signal handlers could cope with any 'tidy-up'
    situation, maybe some people use a different programming 'style'.
    The way I do it means you don't end up with situations where the program cannnot be terminated, whwer you are unable to close windows etc.....................
    Last edited by esbo; 08-31-2006 at 03:58 PM.

  13. #28
    Registered User
    Join Date
    Dec 2005
    Posts
    5
    Quote Originally Posted by esbo
    The trouble with an approach like that is that you risk not being able to close down the program if the program has encountered a problem.
    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?

  14. #29
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,046
    doesn't signal() only need to be executed once for each signal you want handled, not repeatedly in the loop?
    I think so.
    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.

  15. #30
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Quote Originally Posted by s1mon
    Why?
    Because esbo is either a complete idiot, or a troll, and should in my opinion be banned from the form.
    Quote Originally Posted by s1mon
    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?
    Yep to all of the above.


    Quzah.
    Hope is the first step on the road to disappointment.

Page 2 of 3 FirstFirst 123 LastLast
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, 05:21 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21