I reckon this is more to do with the way the terminal is set up, than with any buffering issue. Check the output of
stty -a | grep intr, you should have
intr = ^C; on the output line if Ctrl-C is enabled at the
pty. If it isn't, you can use
stty intr ^C to enable it. Add the line to your
.login to make it permanent (or delete the line that changes it in the first place!).
Failing Ctrl-C, you can also try sending
SIGQUIT with Ctrl-\. If this doesn't work, again check
stty -a | grep quit to see if it is properly set up.
Terminal Emulator Setup
Also check the settings for your terminal emulator (if you are using one), it may be that there is a shortcut set up at this level (maybe for copy or something) and the Ctrl-C does not reach the
pty level. A shortcut could also be set up somewhere else in your desktop environment or Window system.
A good test on Linux if you are using a terminal emulator is to switch to a Linux console (Ctrl-Alt-F1), login there and see if the same behaviour occurs. If it doesn't then this suggests the problem lies with your Window system or terminal emulator.
It could be an issue with the delay between data being read from the
pty device as suggested by peterph. But if this is the case and you do actually have to wait minutes for the data to be displayed, then surely the terminal emulator is buffering way too much data (or your PC is very slow). The answer would be to find a way to reduce that buffer size in your terminal emulator settings or use a different one.
Something else worth adding; I usually end up in the runaway
cat situation when if I accidentally
cat a binary file. The other effect of this can be to screw up your terminal settings (if the binary data happens to match various terminal escape codes which it often does). If
tput is installed (usually is by default), you can avoid having to restart with the following command: