ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
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 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.
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.
'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:
there is frequent communication among the processes; AND
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
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.