[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: C programming, checking for ^C



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. <bss@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.                   ,= ,-_-. =.
bss@iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/


Reply to: