Serial port comms on Linux - why is using SIGIO handler bad?

Question

At work I have been asked to implement a new controller application for industrial hardware using C++ on Linux. A key feature is the use of radio modem communication between devices using modbus. I am able to read and write data to the serial port ttyS0 fine, but I am using a signal handler for the SIGIO signal to tell the main control loop when data has arrived on the port for reading. Timing is crucial as the protocol defines end of transmission as 3.5 character lengths which I need to detect. I have seen on the web that using a SIGIO handler is not a good idea for this purpose (including the answer to this here on stackoverflow ). Can anyone please tell me why this approach is frowned upon? My preference would be to run the incoming message monitoring on a new thread using poll() or select() but my boss is keen on the signal handler approach but we are both new to Linux so any explanation would be gratefully received.

Answer 1

Signal handlers add a great deal of complexity and risk of bugs related to reentrancy and atomicity. You can see a discussion article here: http://www.ibm.com/developerworks/linux/library/l-reent/index.html

It doesn't sound like you have a good reason to use a signal handler for your use case. If your signal handler is just going to signal another thread to do the read, why not just use blocking read or select from that other thread?