ограничения для последовательного порта Асинхронная функция ввода?

Question

У нас есть проект для встраиваемых систем Linux, и мы заинтересованы в производительности.

Пример асинхронного ввода последовательного порта по адресу: http://www.faqs.org/docs/Linux-HOWTO/Serial-Programming-HOWTO.html#AEN105 в значительной степени делает то, что мы хотим.

Однако ответственный инженер возражает против потери производительности процессора зацикленный звонок сна. Он хотел бы, чтобы программа ожидала сигнала для выполнения кода обработки ответа.

Я пытался переместить этот код из main () во внутреннюю функцию сигнала, т.е.

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

Результат не работает, записи в последовательный порт, выполненные в этой функции, быстро завершаются неудачно, и программа перестает отвечать на запросы.

Почему это?

И есть ли у кого-нибудь хороший пример ввода-вывода, управляемого через сигнал, только для одного последовательного порта? Я пролистывал главу 63 книги Керриска "Интерфейс приограммы Linux" и гулял, как сумасшедший. Я начинаю думать, что не может быть лучшего способа сделать первоначальный пример.

Заранее спасибо,

Bert

Answer 1

Если вы беспокоитесь о регулярном пробуждении от вызова usleep(), когда нет доступных входных данных, просто замените вызов usleep() на pause(), который приостановит ваш процесс, пока не произойдет SIGIO.

Answer 2

В общем, делать что-либо сложное (т. Е. Касаться чего-либо за пределами непосредственного стека) в обработчике сигналов опасно - см. http://www.gnu.org/s/libc/manual/html_node/Nonreentrancy.html для довольно подробного описания.Операции ввода-вывода особенно небезопасны, так как они, как правило, выполняют распределение и распределение аппаратного обеспечения и т. Д.

Если вам не нравится явный цикл ожидания, вы можете попробовать использовать семафоры - см. http://linux.die.net/man/7/sem_overview для деталей.В частности, sem_post явно задокументировано как безопасное для использования в обработчиках сигналов, поэтому вы можете поставить (блокирующий) вызов sem_wait в цикле чтения вместо usleep, а затем разблокировать его, вызвав sem_post в вашем обработчике сигналов.