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

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.

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.

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!

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.

> 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.

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.....................

doesn't signal() only need to be executed once for each signal you want handled, not repeatedly in the loop?

I think so.

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.

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.