|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 23 Jan 2003 02:21:30
To : Valentin Nechayev
Subject : Re: научный вопрос
--------------------------------------------------------------------------------
Jan 23 00:27 03, Valentin Nechayev wrote to Zahar Kiselev:
VN> Переназначить одновременно stdin и stdout несложно.
VN> А вот в стандартной библиотеке нет такого потому, что возникает
VN> проблема синхронизации действий по вводу и действий по выводу.
VN> Когда человек сидит за терминалом, он, как event-driven система,
VN> отрабатывает эту синхронизацию беспроблемно. Для программы, которая на
VN> это незаточена, элементарно получить deadlock и прочие "приятные"
VN> ситуации.
Так как "управляющую" программу я собираюсь писать специально под этот случай -
то думаю, что с синхронизацией разобраться будет не особенно сложно.
В этих вопросах мне хорошо помогает опыт паяния схем на мелкой логике - вот где
с синхронизацией возиться много приходилось(до появления electronic workbench -
единственной программы, которой мне не хватает под линуксом).
VN> Иди в ru.unix.prog, поможем ;)
Только что подписался.
ZK>> Вообще-то как минимум один способ мы с приятелем лет пять назад нашли
ZK>> и использовали - через пару псевдотерминалов. Программка та и сейчас
ZK>> работает.
VN> Какой ужас.
А тут не далее как час назад пробежал совет использовать именно
псевдотерминалы:-)
ZK>> Видел однажды
ZK>> исходник, там был трюк с _закрытием_ stdout и открытием "трубы".
ZK>> Вот только не знаю, насколько подобные предположения правомерны -
ZK>> всегда ли это сработает.
VN> Правомерны. Использование первого свободного дескриптора
VN> гарантируется Posix,
Hадо будет подумать в эту сторону...
VN> Вот грабля тут есть - не всегда close() завершается успешно с
VN> закрытием
VN> дескриптора, бывают (хотя крайне редко) и более извратные позы.
"Крайне редко" в моем случае некритично. Графики, которые я собрался рисовать,
относятся к Большому Дизельгенератору, который мы тут на газе заводить собрались
и измерять параметры. Так вот если программа однажды повиснет -
запуск этой железки и набор нагрузки можно и повторить.
Как видишь - я окончательно "забил" на всякую бухгалтерию и снова наукой
занялся. Как оказалось - не один я такой, тут еще несколько технарей собралось,
но вот в программировании кроме меня никто не смыслит...
ZK>> Судя по моим экспериментам - гнуплот похоже и десять раз в секунду
ZK>> работать может если график простой! Hадо только озаботиться
ZK>> синхронизацией, чтобы не "перекормить" гнуплот данными.
VN> Во-во.
Я вот уже час придумываю логику программы - какая ее часть должна читать данные
из АЦП, какая - пересчитывать период импульсов в "обороты в минуту",
какая - показывать эти обороты в виде графика, и как они должны между собой
взаимодействовать. Особенно беспокоит чтение из АЦП - чтобы не "упустить"
производимые им данные. В досе я такие штуки делал - по прерыванию от таймера
или от самой платы АЦП. Данные складывал в буфер, а обрабатывающая часть потом
их оттуда забирала. В полуоси для этого были нити и семафоры. И все равно
сплошной ассемблер и как следствие - долгая отладка.
А как это принято делать в юниксах - не знаю. Hо научиться хочется.
Знать бы где подсмотреть - именно _правильное_ решение.
Сейчас, как только ru.unix.prog у меня появится - изложу там эту задачку...
По-моему все же лучше, чем по десятому разу глюки русификации пережевывать...
Zahar(@spbdept.rbc.ru)
--- Msged/LNX 6.1.0
* Origin: Остров Большой Березовый: http://birch-island.spb.ru (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
