And don't forget to call usleep() or something similar for a short period of time if you're not doing anything in the loop except waiting for Ctrl-C. How short depends on how responsive you want it to be. Otherwise you'll end up with a loop that's constantly looping going round and round and eating 100% of the CPU.
-Steve On 22 February 2011 05:42, Boyd Stephen Smith Jr. <b...@iguanasuicide.net>wrote: > In <ijvej5$q7s$1...@dough.gmane.org>, T o n g wrote: > >I need to check for ^C in an endless loop that doesn't do any stdio. > >How can I do that? > > > >Back in DOS days, I used to use kbhit() from CONIO.H, which checks for > >currently available keystrokes. Is there similar things under Linux gcc? > > Ctrl+C will generally result in your program receiving SIGINT. You can > install a single handler to react to this event. Signal handlers are > somewhat limited in what they can do,[1] but this one should be relatively > simple. Declare a new (global) variable of type sig_atomic_t and set it to > 0 > before entering your loop. Each time around the loop, if it is non-zero, > exit the loop. In your signal handler set the variable to some non-zero > value. > > This isn't DOS, so you don't talk to hardware directly from userspace. All > input is filtered through some tty (serial console), pty (xterm etc.), or > vt > (linux console "virtual" terminals). Those devices track what pid is > currently "managing" them, and when the Ctrl+C arrives turns it into a > SIGINT.[1] There are, of course, ways to go into a "raw" mode where you > get > the Ctrl+C directly, but for your purposes you don't want to do that. Xorg > operates on a "raw" terminal as do some (all?) curses applications. > > [1] Only a subset of the C library is signal safe, and the standard only > provides one type (sig_atomic_t) that is safe to manipulate from from the > main code and signal handlers. Signal handling is asynchronous, so handler > could actually execute *in parallel* with the main body of code. "Green > threads" use this property (and the set-a-flag strategy) to implement > threads > (poorly) on top of SIGALRM. > > [2] This may be wildly incorrect, I'm not exactly sure what turns the > Ctrl+C > into a SIGINT and delivers it to the correct process. It could be the > shell > or some other layer between the hardware and userspace programs. Perhaps > the > terminal handles it until it is put into "raw" mode and then that program > is > responsible for it. > -- > Boyd Stephen Smith Jr. ,= ,-_-. =. > b...@iguanasuicide.net ((_/)o o(\_)) > ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' > http://iguanasuicide.net/ \_/ >
