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.
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.
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:
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!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!" ); }
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.
Originally Posted by darkwalk
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!!!
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.
woot! it works. Here's what I have:
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!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; }
Thanx quzah!
Rather than the stop bit I think an exit(0) at the end of the do_this_last function would be aOriginally Posted by darkwalk
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.
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.
It is normal for the signal handling routine to take care of what needs cleaning up and then exit.Originally Posted by quzah
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!!
> 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.
The trouble with an approach like that is that you risk not being able to close down the programOriginally Posted by Salem
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.
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.Originally Posted by esbo
However, doesn't signal() only need to be executed once for each signal you want handled, not repeatedly in the loop?
I think so.doesn't signal() only need to be executed once for each signal you want handled, not repeatedly in the loop?
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.
Because esbo is either a complete idiot, or a troll, and should in my opinion be banned from the form.Originally Posted by s1mon
Yep to all of the above.Originally Posted by s1mon
Quzah.
Hope is the first step on the road to disappointment.