Почему последовательность чтения не возвращается в конце потока консоли? - PullRequest
Новая
       42

Почему последовательность чтения не возвращается в конце потока консоли?

1 голос
/ 26 сентября 2011

Я открываю последовательный порт с CLISP в Cygwin как поток ввода-вывода и обнаружил, что посимвольное чтение слишком медленное. По какой-то причине поток классифицируется как интерактивный, что, по-моему, приводит к зависанию со значением чтения, меньшим, чем размер моей последовательности.

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

Я вижу несколько разных способов решить эту проблему.

  1. Читайте 1 символ за раз, что позволяет читать "char-no-hang". Это слишком медленно.

  2. Запись FFI в последовательную библиотеку. Я не думаю, что мне нужно это делать.

  3. Найдите способ определить оставшуюся длину потока. Хорошее решение.

  4. Выясните, как сделать последовательный порт неинтерактивным, что может привести к возврату последовательности чтения после завершения потока. Мне кажется, это лучшее решение. 

    (with-open-file (serial "/dev/ttyS3" 
                        :direction :io
                        :external-format :unix
                        :if-exists :overwrite)
                   (read-sequence *data* serial)))

Итак, согласно заголовку, почему последовательность чтения не возвращается в конце потока консоли? Кроме того, каков наилучший способ добиться такого поведения? Я бы предпочел придерживаться базового CLISP.

1 Ответ

1 голос
/ 27 сентября 2011

Сначала проверьте свои определения для ЧИТАЙТЕ ПОСЛЕДОВАТЕЛЬНОСТЬ .

Во-вторых, у последовательных данных не всегда есть маркер конца файла (фактически, обычно нет). Возможно, ваши данные обрабатываются драйвером ttyS3, но если это было необработанное чтение, вы должны предположить, что вам нужно написать свои собственные условия завершения (или реализовать те, которые определены вашим устройством).

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

...