limitations to serial port Asynchroneous Input function?

We have a Linux embedded project and we are concerned with performance.

The Serial port Asynchronous Input example at: http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html#AEN105 pretty much does what we want.

However the engineer in c开发者_Python百科harge objects to the CPU performance lost by the looped sleep call. He would like the program to wait for a signal to execute the response handling code instead.

I tried moving that code from main() to inside the signal function, i.e.:

void signal_handler_IO (int status)
{
    // I moved my code here
}

The result does not work, writes to the serial port made in that function quickly fail and the program becomes completely unresponsive.

Why is that?

And does anyone have a good online example of Signal-Driven I/O for just one serial port? I have been poring over Chapter 63 of Kerrisk's "The Linux Priogramming Interface" book and googling like crazy. I am beginning to think there might not be a better way to do the initial example.

Thanks in advance,

Bert

If you are worried about waking up regularly from the usleep() call when there is no input available, simply replace the usleep() call with a pause(), that will suspend your process until the SIGIO occurs.

In general, doing anything complicated (i.e., touches things beyond the immediate stack) in a signal handler is dangerous -- see http://www.gnu.org/s/libc/manual/html_node/Nonreentrancy.html for a fairly thorough description. I/O operations are particularly unsafe, as they tend to do allocations and poking of hardware and such.

If you don't like the explicit wait loop, you might try using semaphores -- see http://linux.die.net/man/7/sem_overview for details. In particular, sem_post is explicitly documented as safe for use in signal handlers, so you can put a (blocking) call to sem_wait in your read loop in place of the usleep, and then unblock it by calling sem_post in your signal handler.