2013-08-19 4 views
3

У меня два процесса: один C и один python. Процесс C тратит свое время на передачу данных на именованный канал, который затем обрабатывает процесс python. Должно быть довольно просто, и он отлично работает, когда я передаю данные (в настоящее время временную метку, такую ​​как «Mon Aug 19 18:30:59 2013») раз в секунду.Состояние именования труб?

Проблемы возникают, когда я вынимаю сон (1); команды в процессе C. Когда нет никакой второй задержки, связь быстро закручивается. Процесс python будет читать более одного сообщения или отчета, чтобы он считывал данные, даже если его буфер пуст. На этом этапе процесс C обычно бомбит.

Прежде чем я отправлю какой-либо пример кода, мне интересно, нужно ли мне выполнять какую-то синхронизацию с обеих сторон. Как, может быть, говорить, что C-процесс не записывается в fifo, если он не пуст?

Процесс C открывает только именованный канал, и процесс python открывается только как прочитанный.

Оба процесса предназначены для работы в виде петель. Процесс C непрерывно считывает данные по мере того, как он поступает через USB-порт, и процесс python принимает каждое «сообщение» и анализирует его перед отправкой его на SQL Db.

Если я собираюсь просматривать до 50 сообщений в секунду, будут ли названные каналы иметь возможность обрабатывать этот уровень скорости транзакции? Размер каждой транзакции относительно невелик (20 байт или около того), но частота заставляет меня задаться вопросом, следует ли мне смотреть на другую форму межпроцессного общения, например, на разделяемую память?

Любые советы, оцененные. Я могу отправить код, если это необходимо, но на данный момент мне просто интересно, нужно ли мне как-то синхронизировать между этими двумя процессами.

Спасибо!

+2

Можете ли вы привести более конкретный пример того, как сообщение завязано? Что вы имеете в виду бомбы C-процесса? Ошибки сегментации? Дает ли он какой-либо результат, когда он бомбит? – joshlf

+0

Смешная вещь о процессе C - оператор записи на данный момент находится в основном в (1) бесконечном цикле. Когда он сбой, он просто возвращается в приглашение оболочки ... no segfaults. Я обнаружил, что могу воссоздать это поведение в процессе C с помощью CTRL-Cing процесса python. Я бы подумал, что процесс C просто вернется в состояние блокировки записи. – dermur

+0

Я заменил sleep (1) циклом for, который эффективно позволяет процессу C делать около 50 записей в секунду. Кажется, это работает нормально, но я бы хотел, чтобы это продолжалось не менее 48 часов, чтобы быть уверенным в этом. – dermur

ответ

2

Труба - это поток.

Число вызовов write() на стороне отправителя необязательно должно соответствовать числу read() s со стороны приемника.

Попробуйте реализовать какой-то протокол синхронизации.

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

В качестве альтернативы вы можете префикс каждого отправленного сообщения с фиксированным номером длины, представляющим объем данных. Затем приемник может проанализировать этот формат.

+1

Очень верно. Использование разделителя - хорошая идея. Поэтому вместо того, чтобы читать все содержимое именованного канала каждый раз, когда я просто читаю персонажа за раз, пока не дойду до разделителя? – dermur

+0

@dermur: Да, именно так оно и работает. – alk

+0

Хмм, сообщение с фиксированной длиной также имеет достоинства - его, конечно, было бы быстрее прочитать. Возможно, стоит накладные расходы на пустые байты. Спасибо alk - это дает мне пару вариантов игры. – dermur