Tidy exit in C
 

I have written a small C prog that allows me to get sound samples from a sound card or USB device, process them and then output as fast as poss, almost realtime ( I used ALSA and the C lib).
At the mo to end the prog I use CTL+C, which is nasty.
Is there any way (Callback if I knew how???) to set something up so that 'press any key' could be used instead. I tried a few kbhit() variants from t'net happen, but they all caused too much latency.

Thanks

Wait, I don't know what you're really asking.

What's wrong with just reading a line from stdin or something?

stdin is line buffered on a tty by default, so just reading it won't show any data until you hit return. You can put the tty in raw mode, but that's presumably what the kbhit() type functions do.

How about creating a separate thread to listen to the keyboard (with a blocking read)?

I hope you are joking :)

what's wrong with CTRL-C anyway?

I wasn't really joking - I think I've seen systems with listening threads like this - but I agree that it's overkill for a simple case. A signal, with a handler to clean up and terminate gracefully, sounds fine to me.

I think your question is answered in http://www.linuxquestions.org/questi...07#post2570807
If searching elsewhere, I believe this question can be rephrased as 'how do I do non-blocking character-at-a-time terminal IO'. Some other OS's have a function called getch(), which does this, and searching for that can reveal some ansewers, as well.
--- rod.

kbhit()
 

Its ok guys, I have fixed it. Yes a thread would be best but although I can use threads in C++ I have yet to try them in C. Anyway, I discovered 'raw' mode yesterday and now have a very fast kbhit() which works fine.
PS I am a Linux newbie, this is week three for me.

threads are needed in windows beacause it has no decent
process forking. It's Funny this whole threads obsession - I reckon it's come over from windows programmers.
In "Advanced Unix Programming" Richard Stevens himself devotes a few chapters and concludes threads aren't worth the hassle on unix environments (in the vasy majority of cases) because of the cheapness of forking a new process.

right or wrong.

'threads are needed in windows beacause it has no decent
process forking'.
I always understood a fork as a secondary thread of execution. At some point a fork might rejoin the main thread of execution, indeed the fork might be stalled waiting to rejoin, so I wonder if threads and forks are very much the same ? The biggest pain in the butt with windoze (for me) is the task scheduler which loads (10ms ??) latency into any (hah( real time function. My Penguin does not and I love him for it.

no, a unix fork is a cloned child of the parent process.
It never comes back.
they are seperate beings - the child does inherit open network sockets and filehandles but no
sharing of other variables.

Granted this means communication may need to be set up between parent and child, but Mr Stevens
argues that this is much less error-prone than sharing areas of memory and variables
with their inherent problems. (and simpler to debug)

Just my two cents' worth from personal experience.

Threads are useful only if two things are true:

1. there is frequent communication among the processes; AND
2. performance is an issue.

If either one of these is false, use processes and fork() instead.

The main reason is that threads, unlike processes, share their heap. And if you have a thread which is misbehaving because the heap is trashed (typically caused by buffer overrun or use of memory that has already been free()d), it is usually useless to find out when in that thread the heap got trashed, because it's quite likely that some other heap, anywhere in its code, trashed the heap. These bugs are quite expensive to diagnose and fix.

Just not worth it unless absolutely necessary. And if it becomes necessary, keep that sucker as simple as possible.

Thanks for that, its nice to get good explanations if things. Seems UNIX is going to upset my little world but it should all be worth it. I am going to investigate fork() and see what I can do. Its a shame that this (subtley?) wasnt pointed out by my tutors, but heigh ho, everyday something new.
Cheers