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.

Introduction to Linux - A Hands on Guide

This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.

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.

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)

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