|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 25 Jan 2003 00:47:57
To : Zahar Kiselev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
>>> Zahar Kiselev wrote:
VN>> Когда человек сидит за терминалом, он, как event-driven система,
VN>> отрабатывает эту синхронизацию беспроблемно. Для программы, которая на
VN>> это незаточена, элементарно получить deadlock и прочие "приятные"
VN>> ситуации.
ZK> Так как "управляющую" программу я собираюсь писать специально под этот
ZK> случай - то думаю, что с синхронизацией разобраться будет не особенно
ZK> сложно.
Как хочешь. В любом случае это будет или достаточно извращенный (не по
реализации, а по идее) multithreading, или переключение между автоматами
(FSM). Hи один из этих способов не страдает простотой.
Tcl, который тут рекомендовали, удобен именно тем, что в нём заложена
работа с FSM на уровень подложки реализации.
ZK>>> Вообще-то как минимум один способ мы с приятелем лет пять назад нашли
ZK>>> и использовали - через пару псевдотерминалов. Программка та и сейчас
ZK>>> работает.
VN>> Какой ужас.
ZK> А тут не далее как час назад пробежал совет использовать именно
ZK> псевдотерминалы:-)
Так я не говорю, что это трагедия. К сожалению, это единственный способ
избежать полной буферизации вывода по дефолту - в пользу построчной.
VN>> Вот грабля тут есть - не всегда close() завершается успешно с
VN>> закрытием
VN>> дескриптора, бывают (хотя крайне редко) и более извратные позы.
ZK> "Крайне редко" в моем случае некритично. Графики, которые я собрался
ZK> рисовать, относятся к Большому Дизельгенератору, который мы тут на газе
ZK> заводить собрались и измерять параметры. Так вот если программа однажды
ZK> повиснет - запуск этой железки и набор нагрузки можно и повторить. Как
ZK> видишь - я окончательно "забил" на всякую бухгалтерию и снова
ZK> наукой занялся. Как оказалось - не один я такой, тут еще несколько технарей
ZK> собралось, но вот в программировании кроме меня никто не смыслит...
Тогда надо не на зависание планировать, а на вылет.
Расставить такое: if( close( fd ) < 0 ) err( 1, "close()" );
ZK> Я вот уже час придумываю логику программы - какая ее часть должна читать
ZK> данные из АЦП, какая - пересчитывать период импульсов в "обороты в минуту",
ZK> какая - показывать эти обороты в виде графика, и как они должны между собой
ZK> взаимодействовать. Особенно беспокоит чтение из АЦП - чтобы не
ZK> "упустить" производимые им данные. В досе я такие штуки делал - по
ZK> прерыванию от таймера или от самой платы АЦП. Данные складывал в буфер, а
ZK> обрабатывающая часть потом их оттуда забирала. В полуоси для этого были нити
ZK> и семафоры. И все равно сплошной ассемблер и как следствие - долгая отладка.
ZK> А как это принято делать в юниксах - не знаю. Hо научиться хочется.
ZK> Знать бы где подсмотреть - именно _правильное_ решение.
Прерывание от таймера можешь получать через setitimer().
От АЦП - через select() или poll(). Вместе они хорошо совмещаются.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
